-
Notifications
You must be signed in to change notification settings - Fork 309
Add to_dict methods #1705
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
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_dictandto_listmethods to more easily pass OTIO objects tojson.dumps.This is the result from https://academysoftwarefdn.slack.com/archives/CMQ9J4BQC/p1708976729390279.