-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
More cbook deprecations. #7999
More cbook deprecations. #7999
Conversation
The new logic isn't equivalent, but it is certainly a whole lot easier to understand. I am really not sure what edge cases the old logic was trying to catch here. A tenative +1 from me. |
That's why I wrote "more robust", not "equivalent" :-) The old version would get you the incorrect error message when passing incorrect x, y, z with different lengths, for example. |
Jeez, given how much cleaner the new version is, I'm happy so long as no tests break. Don't make it more convoluted until we have tests justifying it. |
@@ -543,6 +543,7 @@ def file_requires_unicode(x): | |||
return False | |||
|
|||
|
|||
@deprecated('2.1') | |||
def is_scalar(obj): | |||
"""return true if *obj* is not string like and is not iterable""" | |||
return not is_string_like(obj) and not iterable(obj) |
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.
is is_scaler
supposed to be broader than is_numlike
?
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.
Arbitrary objects (that are not iterable) are scalars, not numlike. Why?
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.
'cause that confuses me 'cause aren't scalers numbers? What definition of scalers are we using then?
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.
We don't use this function and I exactly don't want to get bogged down into defining what its semantics should be.
lib/mpl_toolkits/mplot3d/axes3d.py
Outdated
# `_is_string_like` matches the behavior of 2D `plot` (via | ||
# `_process_plot_var_args`). | ||
if args and not is_string_like(args[0]): | ||
zs = args[0] |
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.
why is zs = args.pop(0)
a bad idea?
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.
b/c there's no tuple.pop?
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.
:( sorry got mixed up and thought args was a list.
yeah, the results of the tests will be what will convince me that this change is ok. |
`is_scalar_or_string` was not used anymore, `is_scalar` was only used in one place (in mplot3d) and I rewrote that snippet into something more robust.
00dce22
to
863ad9d
Compare
ok, the tests pass. Is there a place in the docs where we are documenting deprecations? Or does that happen automatically with the decorator? |
I think we just grep for |
Thanks! |
|
is_scalar_or_string
was not used anymore,is_scalar
was only used in oneplace (in mplot3d) and I rewrote that snippet into something more robust.