-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Use subplots in examples (rebase) #2043
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
@@ -10,8 +10,7 @@ def data_gen(): | |||
return np.sin(2*np.pi*t) * np.exp(-t/10.) | |||
data_gen.t = 0 | |||
|
|||
fig = plt.figure() | |||
ax = fig.add_subplot(111) | |||
fig, ax = plt.subplots() |
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.
To me this is just as alien as the original. If you just want an axes then ax = plt.axes()
is surely the only sane way of doing it.
If you need access to the figure that the axes lives on then we can make use of the circular OO design inherent throughout matplotlib and do ax.figure
.
Just my 2cents.
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.
On Fri, May 24, 2013 at 9:27 AM, Phil Elson [email protected]:
In examples/animation/old_animation/animate_decay_tk_blit.py:
@@ -10,8 +10,7 @@ def data_gen():
return np.sin(2_np.pi_t) * np.exp(-t/10.)
data_gen.t = 0-fig = plt.figure()
-ax = fig.add_subplot(111)
+fig, ax = plt.subplots()To me this is just as alien as the original. If you just want an axes then ax
= plt.axes() is surely the only sane way of doing it.
If you need access to the figure that the axes lives on then we can make
use of the circular OO design inherent throughout matplotlib and do
ax.figure.Just my 2cents.
Coming from matlab, the "plt.axes()" is what looks alien to me. While
plt.subplots() isn't quite familiar to my matlab sense, at least the name
"subplot" is there and I know that is what I want. Do remember, the
examples section is intended not only to showcase the features of
matplotlib, but also serves two other purposes. 1) establish by example the
coding conventions for using the matplotlib library, 2) serve as the bridge
for migrating users away from other tools. Making the examples familiar to
them, but yet also following best coding practices of matplotlib is a
tricky balance.—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2043/files#r4380788
.
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.
- establish by example the coding conventions for using the matplotlib library
Exactly my reason for brining this up.
I hold neither fig.add_subplot(111)
nor plt.subplots()
close to my heart - it seems to me that we do not want to hide from the fact that the primary plotting area inside a figure is an Axes
(whether you like the name or not) so why, for newcomers reading the examples, do we not show their creation with the very helpful pyplot axes
function? The matlab argument is good, indeed perhaps we could have a section introducing matplotlib for matlab users, but I don't think it should be our main driver for API design...
Making the examples familiar to them, but yet also following best coding practices of matplotlib is a tricky balance
Agreed.
For yet another point of view, I think the question here is which entry point helps people grow from the simplest usage to the most complex, and I think But I'm thinking maybe this PR has become too controversial for 1.3. Also pinging @ivanov as the original mover on this to contribute to the conversation. |
Don't hold this up on my behalf. I haven't reviewed this thoroughly, so I can't say weather its go or no go, but it is certainly an improvement and I'm all for it.
As you can tell, I don't agree (and tend to prefer the iterative construction of subplots to I'm very glad that the use of |
I would like to see this get into 1.3. As @pelson says, it doesn't have to be the last word, but overall it is a substantial improvement. Personally, I have become accustomed to using |
mlab.FIFOBuffer: remove fossil line referring to nonexistent method
BUG: pass kwargs to TimedAnimation
MixedModeRenderer non-72-dpi fixes & Pgf mixed rendering
GTK segfault with GTK3 and mpl_toolkits
BUG: pass kwargs to TimedAnimation
At the recent LBL Software Carpentry Workshop, it was pointed out that there's an inconsistency within our documentation for how to create new figures with subplots. Indeed, most examples were using the old way, something like: fig = plt.figure() ax = plt.subplot(111) # or plt.add_subplot(111) This patch changes a whole bunch of instances like the above to: fig, ax = plt.subplots() We should strive to have a minimal amount of constants in our code, especially unusual ones like `111`, which only make sense to Matlab refugees. I have left unchanged examples which were using axes keywords passed to subplot() and add_subplot(), since those end up transforming things like: figure() subplot(111, axisbg='w') to plt.subplots(subplot_kw=dict(axisbg='w')) which isn't necessarily better. I also did not touch most of the user_interfaces examples, since those did not involve using plt, but instead explicitly imported Figure, and used the OO approach on Figure instances. Also updated instaces where the old "import pylab as p" convention was used to use our standard "import matplotlib.pyplot as plt" I have also updated some, but not all uses of subplot(121) etc, but I'm a bit exhausted after doing all of these.
Manually merged in 33b4cce |
A rebase of #1598, so @ivanov's hard work doesn't go to waste.