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

defmy_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.

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.

This is actually pass 2 at this, see#4488

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 theproposed centerpiece of 2.2, with avery 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 toplt.gca(). The other long term goal is to get away from the shared global state of pyplot (so everything GC's reasonable, etc).

Havingno 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 thanax.XXX(...)

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 theax 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 askeep andneeds comment/discussion because it really something to investigate, but the correct approach is not yet clear.

I could not quickly figure out how to convince the generated annotations to not use the fully qualified class names.

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 returnNone.