-
-
Notifications
You must be signed in to change notification settings - Fork 8k
ENH: add ax
kwarg to every pyplot function
#9111
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
e95b2b8
to
4d4662e
Compare
What's the benefit as opposed to just using the OO API, if you really want to specify the figure/axis?
This is the opening pass at something I have been thinking about for a while.
The very short version is that there is currently a major difference between 'built in' plotting (ax.foo(data, style)
) and user / third-party plotting (foo(data, style, ax=ax)
) and it would be better to reduce. As we do not want third-party tools to be monkey-patching methods on to Axes, we should rotate the main API to look more like functions to put everything on the same footing. The suggested API would then be
def my_plotter(*data, ax, **style): ...
This is bread-crumbs leading that direction.
This actually looks like a reasonable argument (as much as I would like not to admit it...)
In general I'm ok with the idea. I do think we should think about the idea of plotting objects in this context before proceeding, though.
Also what's wrong with just using sca() in that case?
Or even
with plt.sca(ax): ...
which is probably going to be less repetitive that having to pass ax again and again.
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.
If for no other reason than that this allows using the pyplot
interface with an explicit axes, I'm 💯 on this.
I think that this and more complex objects are orthogonal. The objects are about making more complex plots easier to update and work with (ex errorbars) and this is about letting third-party code, or code that takes in not-arrays as input feel like first class citizens next to the 'official'.
I expect there to be plotting functions that take in very non-array things (like a partial sql query!).
It also provides a smoother path to leaving the fully implicit world to the full OO world.
54215b7
to
1bbbed8
Compare
This is actually pass 2 at this, see #4488
b08714c
to
f26efd9
Compare
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 just test that len(ax1.lines) == 2 instead of doing an image comp.
test name has typo ("explicit")
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 should be one line per axes (gca()
is surprising! ax2 was created last so it is 'current')
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.
you got me :-)
but still you should be able to just test how many lines there are on each axis.
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.
Done
tools/boilerplate.py
Outdated
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.
the comment above needs to be updated
side point: I think we should just throw an exception in this case -- the parameter name is part of the API so renaming it seems silly
198eb48
to
ccabef7
Compare
tools/boilerplate.py
Outdated
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 was suggesting to do the same for washold and ret below.
Even if this turns out to be the way to go, bringing in such a major strategic change with so little discussion and review is not good. Suggestion: leave this out of 2.1, and make it the proposed centerpiece of 2.2, with a very short release cycle--say, Nov. 1 as the target.
It was worth a shot!
I am taking @efiring 's comment as a veto of this going in for 2.1.
Delaying to 2.2 in Nov would give us time to write some collateral around this change, flesh out some of the other implications, and retroactively write a MEP which is probably for the best
Having though a bit about this, right now I belive my preferred take on such an API ("to make pyplot and external functions more symmetrical") would be
with plt.sca(ax): # or a new function
plt.plot(...)
seaborn.somemethod(...)
# when sca() is *exited* there is *no* current axes,
# so plt.gca() would return None and plt.plot would error
which seems better than having to pass the same ax again and again.
However this means inside of every function there must be a call to plt.gca()
. The other long term goal is to get away from the shared global state of pyplot (so everything GC's reasonable, etc).
Having no current figure/ax is a non-starter. pyplot
(and all of it's shared global state) exists as convince methods for people sitting in an interactive shell and I do not think we will ever be able to remove it, just make it possible for people to use without it.
Having a context manager that resets the current axes to what it was before would be a reasonable thing though.
XXX(..., ax=ax)
is not that much more onerous than ax.XXX(...)
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.
In terms of code, this looks good, but the PR introduces a backward incompatible change.
On the documentation front, a lot of the docstrings need to be updated to reflect the addition of an optional keyword argument. I'm happy to push the missing documentation.
I'm also concerned about the unit tests. While indeed, this has been tested on one of the pyplot function, I think we should maybe write smoke tests coverage all pyplot functions concerned by this change.
lib/matplotlib/pyplot.py
Outdated
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 will fail if args has more arguments than one. If args is can only be one optional argument, why not change *args into an actual optional keyword argument? That would make the code more readible, and more easily documentable than currently.
Note that because of this line we are currently introducing a backward compatible change with this PR.
lib/matplotlib/pyplot.py
Outdated
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.
The docstring needs to be update to reflect the addition of an optional keyword argument.
lib/matplotlib/pyplot.py
Outdated
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.
The docstring needs to be update to reflect the addition of an optional keyword argument.
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.
👍
lib/matplotlib/pyplot.py
Outdated
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.
The docstring needs to be update to reflect the addition of an optional keyword argument.
98c8f53
to
2cb8655
Compare
rebased to keep the dream alive.
Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.
As a side-note: The place where the ax
keyword is most present is the pandas plot API. Unfortunately, they have a different semantic ("if not given, create a new axes" vs. pyplot: "if not given, use the current axes - only if there is no current axes, create a new one).
Not necessarily a blocker, but we have to be aware that this will be a source of confusion.
I've marked this as keep
and needs comment/discussion
because it really something to investigate, but the correct approach is not yet clear.
This allows passing `ax=some_ax` or `fig=some_fig` into all of the pyplot plotting functions.
2fc6e64
to
e0178fb
Compare
I could not quickly figure out how to convince the generated annotations to not use the fully qualified class names.
Bit confused why it was not hitting these before.
mypy is still also a bit unhappy (it does not like forwarding returns through unconditionally...I guess the fix would be to make the generating code smart enough to drop the return if the wrapped function claims to only ever return None
.
This allows passing
ax=some_ax
into all of the pyplot plottingfunctions.
PR Checklist