Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Implements a different approach for __repr__ #78
Implements a different approach for __repr__ #78
Changes from 5 commits
4f335ed
5d8a033
eb98987
b482bef
019abe4
73f1aef
8da17d3
70857de
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 would go the opposite route; include rather than exclude. There are lots of types, and if we aren't going to test them all then we should only include the ones we know work. I expect printing meshes and MObject types to also be problematic. Only the float, double, bool and string are interesting, possibly enum too.
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.
Instead of adding more checks into the repr, I thought, since
self.typeClass()
is doing all the heavy lifting, I should use that info instead.I had to add a couple more types since a lot of these are types of some basic queries like
node['transform']
ornode['rotateX']
but this is what I came up with:Which worked, with the exception of when the type has not been implemented, since
self.typeClass()
raises an error. This happens specifically with the following doctest on line 4180:That is because
isHistoricallyInteresting
is a kNumericAttribute ofkByte
NumericData, which isn't supported inself.typeClass()
I could add a try except in the repr like so and then not read() the value:
But then the doctest above fails for a different reason:
Would it be ok to remove the value return from that test? Also, in regards to having a try except in the
__repr__
, I'm not so sure about that idea either, but inevitably there will be cases where the attribute isn’t implemented in typeClass, so it has to account for that.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.
Hm, true.. Choices choices.
In that case, I think we can just put whatever comes out of
str(plug)
after the==
. It can be a try/except; if it fails, we do not include the==
. It's a__repr__
after all, for debugging. Not performance sensitive or in need to be exact. Then we could potentially work, separately, on making more values print nicely viastr(plug)