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
Reactivating pyplot.subplot
throws warning.
#12513
Comments
That has been discussed at length in #7377 (comment) and linked issues. TLDR: the current implementation is quite brittle. I think the correct way is indeed to store a handle to the axes and call As a side note, it looks like the warning gets lost by sphinx-gallery. There should probably be an option to emit these warnings, and even better fail the build in that case... |
This code example is not executed by sphinx-gallery, it's just some code in the text. I suppose we do not want to let these kinds of code snippets being parsed at all, since there is no guarantee that they are even runnable. The discussion in #7377 doesn't actually consider the case of |
Oh, sorry, I completely missed that. I think that specific example could be run, though. |
I think this issue is pretty important. If everything stays as it is now, the pure pyplot interface will not be able to handle subplots anymore. So I want to make sure everyone is aware of the consequences. |
For better or worse, there are users out there who rely on being able to call |
It would be nice to move this handling out of Axes/Figure and into pyplot, but in the meantime I guess one can just revert the warning... |
I am using a very similar version to you (2.2.3 I think) and the following line gives me no warning - # fig is the figure and inside it is ax
fig, ax = plt.subplots(figsize=(12, 6)) And then you can just simply add the following code - ax1.set_title('Easy Peasy!') # Title
ax1.set_xlabel('Some Numbers') # X-axis Name
ax1.set_ylabel('Some Number') # Y-axis Name
ax.plot([1, 2, 3, 4], [1, 4, 9, 16])
plt.show() I hope that helps! |
I am definitely not a fan of this change. One thing I have appreciated about python is that you can do OOP or not, and this break that. Trying to force a particular style of programming doesn't seem very pythonic - and this seems to be the uniform response to the questions raised about this change. Something like "use the OOP syntax" or "store the axes yourself" is all I can find. For example, what is the recommended way of handling the following - which is the original question of the post. This situation came up today in my workflow for a real problem, but I boiled it down to a simple case. We start with a simple subplot arrangement and some data:
Now, I then realize that the matrix z should have 30 points instead of 10, and a slightly different x-axis. No problem!
...but now we have that deprication warning! Notice how the structure of the second example matches the first. It was a simple copy/paste and easy to develop. What's the recommended solution now? Something like this?
Something else? No matter what, you break the symmetry, and make it harder to develop the code, and make it harder to read. This kind of case happens a lot in my workflow. As a hack I will probably do something like:
|
I think
Should work, and not have a deprecation warning. I.e if that subplot exists it should become the current axes, but not be erased. I’m confused if that’s what happened before. |
I totally don't understand what this response means. The symbol "I" doesn't exist, so plt.subplot(2, 1, I) won't work. plt.cla() clears the axis, which is not at all what I was asking about, nor what the original poster was asking, so I must be missing something here. Could you modify my simple problem above into something runnable? The problem is that if you call, say, subplot(2,1,1) at one point, and then want to add to that same subplot (after doing a number of other subplots) you'd like to be able to do subplot(2,1,1) again to select that axis again without having to store the intermediate value. That was the old behavior and has worked well for over a decade, and certainly behaves like matlab's subplot works. the new deprecation seems to be warning that it will break that. |
@bblais, plus or minus a typo, I am agreeing with you... |
The original issue was with |
In #9024 someone complained that |
Yes, the axes() behavior would be surprising. However, subplot has always worked this way for the reasons I pointed out before. If they could be separated, that would be terrific! |
I am having this issue with matplotlib 3.2.1. Can you confirm that there is no real risk of deprecation here and that plt.subplot will work intuitively (i.e. reactivate an axes if it already exists) in the future? If so, is there a way to mask the warning in the meantime ? |
Please be careful when using "intuitively" to describe software. It is very dependent on your personal experience and context. Behavior that one person finds "intuitive" another may find counter intuitive. The implicit "current axes" logic behind plt.subplot(222)
plt.subplot(122)
plt.plot(...)
some_helper(...)
plt.plot(...) # <- which axes does this plot to?! It is impossible to tell what axes (or really what what Figure!) that last plot is going to go to without reading If instead you write fig, (ax1, ax2) = plt.subplots(1, 2)
ax1.plot(...)
some_other_helper(ax1, ...)
ax2.plot(...) there is no ambiguity. Given that this has been documented forever, we probably can't actually let this break. @durandg12 Would you mind take a look at how fix this so this usage does not warn or raise, but so that we can remove the behavior of |
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help! |
AFAICT this no longer warns. Feel free to ping for reopen if I got this wrong. |
Yes, it was fixed by #19153. |
Bug report
Bug summary
Running
plt.subplot
after the respective subplot has already been created shows a warning. This behaviour is expected forfig.add_subplot
. However in pyplot this is to my knowledge the recommended way to activate a subplot, as seen from the tutorial.Code for reproduction
The following is the code from the second code box in the Working with multiple figures and axes section of the basic pyplot guide.
Actual outcome
When being run it produces a warning.
Expected outcome
No warning. Using
pyplot.subplot(211)
should just activate the subplot, as described in the tutorial.Alternatively, there needs to be another way to activate a subplot in pyplot (without having stored any handle to it previously).
Matplotlib version
The text was updated successfully, but these errors were encountered: