Skip to content
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

Use subplots in examples (rebase) #2043

Closed
wants to merge 13 commits into from
Closed

Conversation

mdboom
Copy link
Member

@mdboom mdboom commented May 21, 2013

A rebase of #1598, so @ivanov's hard work doesn't go to waste.

@mdboom mdboom mentioned this pull request May 21, 2013
@@ -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()
Copy link
Member

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.

Copy link
Member

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 notifications@github.comwrote:

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
.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mdboom
Copy link
Member Author

mdboom commented May 24, 2013

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 plt.subplots wins on that account, so introducing people to it early (though it's a somewhat recent addition) makes a lot of sense.

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.

@pelson
Copy link
Member

pelson commented May 24, 2013

But I'm thinking maybe this PR has become too controversial for 1.3.

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.

I think the question here is which entry point helps people grow from the simplest usage to the most complex, and I think plt.subplots wins on that account, so introducing people to it early makes a lot of sense.

As you can tell, I don't agree (and tend to prefer the iterative construction of subplots to subplots anyway) but that is fine - just because we don't agree doesn't mean we can't move forwards.

I'm very glad that the use of plt.subplot(111) all over the place is out - and if I, or anybody else, feels passionately enough about it then another improvement is just a PR away (this is open source software after all!). 😉

@efiring
Copy link
Member

efiring commented May 25, 2013

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 subplots routinely because it is a nice, concise, flexible one-stop-shop. I've never used plt.axes and didn't even notice that it existed. I'm a bit uncomfortable with the ubiquitous circular references in mpl, so I like being able to start out with the reference to the Figure object, even if I don't actually need it in the end--but usually I do need it.

efiring and others added 13 commits May 25, 2013 13:20
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.
@mdboom
Copy link
Member Author

mdboom commented May 28, 2013

Manually merged in 33b4cce

@mdboom mdboom closed this May 28, 2013
@mdboom mdboom deleted the use-subplots branch August 7, 2014 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants