-
Notifications
You must be signed in to change notification settings - Fork 36
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
4f335ed
Implements a different approach for __repr__
chelloiaco 5d8a033
Fixes Python2.7 compatibility for doctests
chelloiaco eb98987
Reimplements old doctests without .name(), .path() and .read()
chelloiaco b482bef
Changes the repr diplay to be more code-like
chelloiaco 019abe4
Skips read() call within Plug __repr__ if the plug's apiType is of ty…
chelloiaco 73f1aef
Delegates Plug __repr__ value reading to __str__
chelloiaco 8da17d3
Removes try/excepts and implements test case for string plugs
chelloiaco 70857de
Fixes if statement for not isCompound/isArray
chelloiaco File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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)