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

Remove instances of %matplotlib inline #9

Open
choldgraf opened this issue Mar 20, 2017 · 7 comments
Open

Remove instances of %matplotlib inline #9

choldgraf opened this issue Mar 20, 2017 · 7 comments

Comments

@choldgraf
Copy link
Contributor

See here for a discussion of this. Basically, when we use %matplotlib inline it tends to create confusion when exporting notebooks to python scripts (because this line will cause python to break, since it's ipython-specific).

I think the jupyter team is working to auto-convert these kinds of one-liners, but I think in the meantime we should discourage the use of %matplotlib inline to avoid this problem.

One solution is to:

  1. Ensure people are using matplotlib 2.0 (which will choose the right plotting backend automatically)
  2. Call plt.ion() at the beginning of scripts, which causes plots to show up automatically

What do people think about this? I think it's a fine solution if we assume people are using MPL 2.0.

@mpacer
Copy link

mpacer commented Mar 20, 2017

You should note in these lessons that plt.ion() stands for "interactive mode on" (see here).

But this is part of a more complicated issue; it would be worth looking at the docs on interactive mode for seeing what exactly it means to not be running in interactive mode.


Basically, when we use %matplotlib inline it tends to create confusion when exporting notebooks to python scripts (because this line will cause python to break, since it's ipython-specific).

Actually, the problem here is not just that it's ipython specific; that is, it will also fail if you run jupyter nbconvert your_notebook.ipynb --to python && ipython your_notebook.py because the inline backend doesn't work outside of the notebook. For other magics though running jupyter nbconvert your_notebook.ipynb --to python && ipython your_notebook.py may be enough to get it working.

After a discussion today with @fperez, @Carreau, @JamiesHQ and @ian-r-rose, the current plan does not include fixing the general ipython magic to script export problem. IPython magics use a lot of the IPython scaffolding to accomplish complicated tasks with minimal user effort. As soon as you export to a python script, without adding that scaffolding back by executing the script with ipython magics will necessarily cease working.

Note, if all you want to do is to get images out of a notebook outputs you should be able to use the --extract-output flag in nbconvert. This should work no matter what matplotlib backend (and whatever magics) you are using.

@choldgraf
Copy link
Contributor Author

@hlapp what do you think about me removing the use of %matplotlib inline and replacing it with plt.ion + a message saying students should use matplotlib 2.0?

@hlapp
Copy link
Contributor

hlapp commented Mar 23, 2017

I think that would be great.

The cell magics may be worthwhile material in a course teaching chiefly Jupyter and/or Python. But for this curriculum, the overarching subject is reproducible research, or more concretely, practices using Jupyter Notebooks that make your computational research more reproducible. If cell magics occur we would not normally explain them or what exactly they do, because that would mostly be a distraction from what we're really trying to teach here. Also, by their very nature (inducing behavior that's not reproducible outside of a Jupyter notebook) they're not exactly consistent with the subject we are teaching.

So replacing them with something that requires less special explanation, and that can run with Python even if the Jupyter NB environment is peeled away, would seem broadly desirable to me. So long, as seems to be the case here, as satisfying the required dependencies doesn't take jumping through many additional hoops.

@JamiesHQ
Copy link

JamiesHQ commented Mar 23, 2017

Thanks @choldgraf & @hlapp - sounds like a good workaround for the purposes of the lesson. Let me know if Chris' solution is satisfactory enough to close the issue - or @choldgraf you can do it! This isn't Jupyterland!

@choldgraf
Copy link
Contributor Author

I'll make a PR to do this soon, let's close this issue once that gets merged :)

@choldgraf
Copy link
Contributor Author

actually I just took a look through some notebooks and this is going to take a little bit of time...some of the weeks are not super clearly organized to me and it's also a little unclear where there is matplotlib stuff going on and where there isn't. I'll make any edits as I look through the materials I'll use next but I don't have the time to go through each notebook individually right now.

@JamiesHQ
Copy link

@choldgraf that makes sense. There is discussion around doing another pilot partnered with a working session, so we can tag it as a to-do before then.

@JamiesHQ JamiesHQ added this to the Before Pilot 2 milestone Mar 24, 2017
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

No branches or pull requests

4 participants