-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Fix specifying number of levels with log contour #27576
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
Conversation
e0abbc2 to
a0c5e26
Compare
a0c5e26 to
f495d8d
Compare
f495d8d to
9cd6171
Compare
e908660 to
042e55a
Compare
|
Thanks - as well as applying your suggestions, I also factored out the logic to set the locator if it's not already set. This allows the long docstrings to be split up, and makes it explicit in |
| if args: | ||
| # Set if levels manually provided | ||
| levels_arg = 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.
This could still be made clearer / the current code is still convoluted (but possibly better as a followup PR to not make too many changes and complicate review)
args is not the original args but stripped from leading [X, Y], Z. Effectively it can only be empty or contain a single element that contains levels passed positionally (which is supported, but a bit cumbersome to write out as a signature because the optional [X, Y] require to absorb all positional parameters in *args and we therefore have to reunite a possible positional level from args with the possible kwarg level.
The current implementation also has the surprising side effect that you can do contour(Z, levels1, levels=levels2) and the positional levels1 is sliently ignored.
The only use of args here is to pass on a possible positional level. We can push the logic out of the function and unite the positional and kwarg paths of levels in the caller _contour_args - where it belongs logically.
I think eventually we should also make levels kw-only. contour(Z, 5) or contour(X, Y, Z, [-1, 0, 1]) are not very readable anyway.
cb2a823 to
8c0775e
Compare
|
I've milestoned this as 3.11 because it changes longstanding behaviour (even if it is a bugfix) |
PR summary
When plotting contours with a log norm, passing an integer value to the
levelsargument to cap the maximum number of contour levels now works as intended. Partially addresses #19856 and replaces #25149.I've maually checked that the added test fails before this fix. Testing with the following script:
Gives on current
main:and with this PR:
PR checklist