Simplifying code

[Atcold]

Most, if not all, np., plt., ax., fig., and mpl. can be safely removed if importing * directly in the main name namespace. Currently there are so many useless repetitions, IMHO.

from matplotpib.pylab import *

would make things much cleaner and simple.

[jklymak]

... but more ambiguous and error prone. Overall, we are working to move matplotlib away from state-based Matlab-inspired interface to the more pythonic object oriented interface.

[timhoffm]

Additionally, the pylab wildcard import is discouraged due to namespace pollution (e.g. it silently overloads builtin sum() with np.sum(), which behave differently in some corner cases).

Those prefixes are recommended best practice and thus need to stay.

Anyway, thanks for taking the time to suggest improvements on the cheat sheet!

[Atcold]

@jklymak, I really hope it's not going to be the case. Now matplotlib's pylab turns your terminal into a Matlab replacement. I constantly have it open and use it for any quick computation on the fly. Then sure, if I'm writing a script, I'm using OOP. But that's quite rare.

@timhoffm, yeah, for programming. I agree. But for live data exploration they are just slowing your train of thoughts. If you do math with a computer you don't really care what package is bringing in what feature. I'm not sure if I'm delivering the idea / message.

In summary, matplotlib's pylab gives you an interactive calculator. Then, sure, it can also be used for scripting. But I don't think it's its primary usage. And the cheat sheet is targeted for the first group of users, IMHO. Programmers check the API or StackOverflow.

[mdehoon]

I fully agree with @Atcold here. Usually the first thing I do after starting Python is

>>> from pylab import *

I appreciate that the prefixes np., plt., ax., fig., and mpl. have the advantage of showing specifically which module or object is being used, but in practice I find it only matters when I am writing a script to be used for all eternity. In daily life, I almost never use the prefixes, and I would find it annoying if I had to use them all the time.

[jklymak]

I used matplab for many years. Anytime I did actual data analysis that I didn't store in a script, I always regretted. Making a figure on the fly is very rarely a good idea because you can't go back and fix it if you've not stored the commands you used to make it.

That all said, I don't think we are actually planning to remove pylab. But we are certainly not going to advertise it in a cheatsheet because we don't feel it is best practice.

[timhoffm]

In summary, matplotlib's pylab gives you an interactive calculator.

On a side note, I don't think this is the responsibility of a visualization library. If designed from scatch, that would be a separate library. Even though, we don't recommend pylab it will stay.

Then, sure, it can also be used for scripting. But I don't think it's its primary usage. And the cheat sheet is targeted for the first group of users, IMHO. Programmers check the API or StackOverflow.

The cheat sheet is targeted at all users of matplotlib. It's also much simpler for pylab users to ignore prefixes in the cheat sheet than for others to guess them if they weren't there.