-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add to_dict methods #1705
base: main
Are you sure you want to change the base?
Add to_dict methods #1705
Conversation
…o_list to AnyVector. Useful to pass to json.dumps. Signed-off-by: Jean-Christophe Morin <[email protected]>
Signed-off-by: Jean-Christophe Morin <[email protected]>
|
||
|
||
@add_method(AnyDictionary) | ||
def to_dict(self): # noqa: F811 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced that this is the best name. Should we instead call it to_py
? It would be more generic. I don't like that we have to_dict
on everything except AnyVector
which has to_list
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to_json
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no type named json in Python. to_json
to me means "to JSON formatted string". And it's not json specific, it's really just a pure python data structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I see what you mean. to_py
is indeed more generic then, even if it's a bit less intuitive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to_dict
and to_list
over to_py
.
That way you know what you get.
Of course the nature of the object will indicate what to_py
returns, but I still prefer the explicitness of to_dict
and to_list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't mind using to_dict
because I'm used to seeing and using this to make a complex structure a simple dictionary. To me it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to_py
would allow us to iterate through a list of OTIO objects (of any type) and convert them to python types without using isinstance
to pick the right method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow up to this, I ended up having to make a helper function to do exactly this at work. I ended up calling the function pythonify
to communicate its returning Python objects.
to_py
seems in line with other conversion method names on OTIO objects and is clear of what to expect. Another reason to use a py
/python
name is because AnyDictionary
and AnyVector
can nest each other so you're not just getting a dict
or list
but rather the entire struct is pythonify
-ed.
413f418
to
2c0612e
Compare
Signed-off-by: Jean-Christophe Morin <[email protected]>
2c0612e
to
d19d487
Compare
This is ready to review. I would need help with the model regeneration. I'm not too sure what's going on with that. |
I think we're thumbsup on adding this. The test failure is a bit of a head-scratcher - we'll need to look in this vicinity to determine why the module path is coming out wrong in the docs. |
If this is doc related it might be that you'll need to run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good to me assuming the CI failures are unrelated to the implementation itself.
Add
to_dict
andto_list
methods to more easily pass OTIO objects tojson.dumps
.This is the result from https://academysoftwarefdn.slack.com/archives/CMQ9J4BQC/p1708976729390279.