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

Out of context and misleading instruction for saving figures #35

Open
hlapp opened this issue Aug 15, 2018 · 7 comments
Open

Out of context and misleading instruction for saving figures #35

hlapp opened this issue Aug 15, 2018 · 7 comments
Labels

Comments

@hlapp
Copy link
Contributor

hlapp commented Aug 15, 2018

The lesson states the following in section Saving your plots as image files:

If you'd like to save your plots as an image file, you can run fig.savefig('my_figure.png') where "my_figure" is the file name.

This won't work, and it's non-trivial to recover to a way that it does:

  1. There is no variable fig here. Normally (in matplotlib documentation commonly found) this is the return value of plt.figure(), but we are not using this method here. Instead we use Seaborn.boxplot(), which does not return an equivalent value.
  2. plt.savefig() would work (as one can find out from testing autocompletion alternatives), but appears to have to be in the same code cell as the one generating the plot. I.e., we can't just insert a new cell here and run this method.
@hlapp
Copy link
Contributor Author

hlapp commented Aug 15, 2018

@dleehr FYI.

@hlapp hlapp added the bug label Aug 15, 2018
@choldgraf
Copy link

My 2 cents is that it'd be better to make sure that earlier on we create a fig variable, and then keep the fig.savefig method, as opposed to using plt.savefig. I think the former is more in-line with how Matplotlib "prefers".

@hlapp
Copy link
Contributor Author

hlapp commented Aug 20, 2018

@choldgraf I agree with your argument, but am wondering how to apply this here where we are using the seaborn package.

There may well be an easy interface to obtaining the fig variable value, but I don't know enough about Python (or plotting in Python) to suggest how.

@choldgraf
Copy link

argg, I just looked through this notebook and it's actually using the non-object-oriented API for Matplotlib all the way through, which IMO is not recommended practice.

Would folks be OK with me taking a pass and changing the Matplotlib to use the object-oriented api instead of the pyplot api? E.g. doing:

fig, ax = plt.subplots()
ax.scatter(x, y)

instead of

plt.figure()
plt.scatter(x,y)

the former is recommended by the matplotlib community, while the latter is allowed more because a lot of Matlab people already want to plot with that API

@choldgraf
Copy link

(and to that extent, does anybody know what the _run notebook is for?

@hlapp
Copy link
Contributor Author

hlapp commented Aug 20, 2018

I'd be all for moving the lesson to using recommended practices. I think the fraction of people in these workshops who are coming over from using Matlab is small. Also, other lessons in this curriculum, in particular the automation one, does I think use the object-oriented API, which was the source of some confusion among the students. (In fact I myself had been under the impression that the reason we're using the pyplot API is because it's what the Jupyter Notebook environment needs for plotting inline. Apparently that's false?)

@hlapp
Copy link
Contributor Author

hlapp commented Aug 20, 2018

(and to that extent, does anybody know what the _run notebook is for?

It's the one now pointed to on Mybinder.org by the Sharing lesson, as the example for sharing an interactive live Jupyter Notebook. It's in essence a copy of the instructor's version of the notebook, with the interspersed and trailing exercises etc deleted.

Easy enough to recreate as a copy, I should add.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants