pylab overwrites user variable(s)

[klonuo]

>>> f=10
>>> from pylab import *
>>> f
<built-in method f of mtrand.RandomState object at 0x00DC2510>

[WeatherGod]

Not a bug (technically). Your imports should always come first. This is also another example of the dangers of "from foobar import *".

[dmcdougall]

Yup:

>>> f = 10
>>> import pylab as p
>>> f
10
>>> p.f
<built-in method f of mtrand.RandomState object at 0x1083341b0>

[mdboom]

I agree about the dangers of from foo import * and it should be discouraged. But in this particular case, this isn't really something we intended to share -- it's just a transient local variable. Ideally pyplot.f wouldn't get this object either. Adding a del f in there somewhere might be nice -- and I wonder what other things that might apply to.

[klonuo]

I noticed this in IPython. I wanted to plot some data and after entering %pylab mode, it overwrite my file handle (hdf5) which was assigned to f and all it's descendant objects that were connected to it.

f can usually be seen in examples as file object variable and personally I don't think it's good idea one letter function to be exposed like this.

[pelson]

The problem comes from numpy:

numpy.random.f
<built-in method f of mtrand.RandomState object at 0x7ff048559168>

Which is imported in pylab.py line 262.

I'm not sure we can reliably do much here other than del f as @mdboom says (but wont that still clobber @klonuo's f variable). Perhaps the best approach is to remove it upstream in numpy?

[pelson]

Note, the offending numpy line: https://github.com/numpy/numpy/blob/master/numpy/random/mtrand/mtrand.pyx#L4481

[WeatherGod]

On Thu, Dec 6, 2012 at 4:21 AM, Phil Elson notifications@github.com wrote:

The problem comes from numpy:

numpy.random.f
<built-in method f of mtrand.RandomState object at 0x7ff048559168>

Which is imported in pylab.py line 262https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/pylab.py#L262
.

I'm not sure we can reliably do much here other than del f as @mdboomhttps://github.com/mdboomsays (but wont that still clobber
@klonuo https://github.com/klonuo's f variable). Perhaps the best
approach is to remove it upstream in numpy?

Nope, it won't clobber it. See following example:

foo.py:
a = 10
del a

bar.py:
a = "waka"
from foo import *
print a

$ python bar.py
waka

But in the end, perhaps we need to consider just explicitly importing in
the features we want? This could help protect against changes in the
codebases, which has happened before. The problem I see with that approach
is the risk of missing something that someone actually needed.

[pelson]

But in the end, perhaps we need to consider just explicitly importing in the features we want?

tbh, to beat an already well beaten drum, the whole pylab thing is the fundamental problem here. To quote the zen of python:

Namespaces are one honking great idea -- let's do more of those!

The problem I see with that approach is the risk of missing something that someone actually needed.

Agreed. I would sooner do it the other way round - i.e. del the names which people report as conflicting, rather than having the unknown of how many people that a change would effect. After all, the easy workaround is to import pylab before defining your own variables...

[mdboom]

Yeah -- it's not an easy problem. Though I agree for scripts/code it's almost never a good idea to import *, in the IPython pylab mode it can be rather convenient to have lots of things at the top level.

It's never really been defined what's supposed to be in pylab -- it includes things both from matplotlib and numpy (deliberately), but not by explicitly listing things -- so it's kind of dynamic based on the contents of numpy and pyplot. So it's kind of a slippery slope to start removing things when end users may be relying on them being there. I know I was the first to suggest it, but maybe it's best to just not tackle this at all. We already encourage users to do from matplotlib import pyplot as plt wherever we can, and barring that, keeping any import * at the top of scripts, and not entering pylab mode in ipython midstream should also be encouraged.

I guess I'm starting to see that instating a policy of trying to prune pylab may lead to a very unbounded project.

[efiring]

To be more blunt, pruning would be a big mistake. Where would one stop? Why should some names start to disappear, while other likely variable names would not? In that list from RandomState, "f" is not the only name commonly used as a variable--consider "beta", "gamma", "seed", "choice"--all perfectly reasonable variable names that a user might want to use. And "f" is as much a valid standard name for its function as the other names in that group are for theirs.

This is a clear "won't fix" case.

[jenshnielsen]

Also note that the from pylab import * in Ipython can be disabled with:
c.InteractiveShellApp.pylab_import_all = False ect in the IPython config