Re: [Matplotlib-users] [Numpy-discussion] rant against from numpy import * / from pylab import *

Sebastian Haase wrote:
> Hi!
> I use the wxPython PyShell.
> I like especially the feature that when typing a module and then the
> dot "." I get a popup list of all available functions (names) inside
> that module.
> 
> Secondly,  I think it really makes code clearer when one can see where
> a function comes from.
> 
> I have a default
> import numpy as N
> executed before my shell even starts.
> In fact I have a bunch of my "standard" modules imported as <some
> single capital letter>.
> 
> This - I think - is a good compromise to the commonly used "extra
> typing" and "unreadable"  argument.
> 
> a = sin(b) * arange(10,50, .1) * cos(d)
> vs.
> a = N.sin(b) * N.arange(10,50, .1) * N.cos(d)

I generally do the latter, but really, all those "N." bits are still 
visual noise when it comes to reading the code--that is, seeing the 
algorithm rather than where the functions come from.  I don't think 
there is anything wrong with explicitly importing commonly-used names, 
especially things like sin and cos.

> 
> I would like to hear some comments by others.
> 
> 
> On a different note: I just started using pylab, so I did added an
> automatic  "from matplotlib import pylab as P" -- but now P contains
> everything that I already have in N.  It makes it really hard to
> *find* (as in *see* n the popup-list) the pylab-only functions. --
> what can I do about this ?

A quick and dirty solution would be to comment out most of the imports 
in pylab.py; they are not needed for the pylab functions and are there 
only to give people lots of functionality in a single namespace.

I am cross-posting this to matplotlib-users because it involves mpl, and 
an alternative solution would be for us to add an rcParam entry to allow 
one to turn off all of the namespace consolidation.  A danger is that if 
someone is using "from pylab import *" in a script, then whether it 
would run would depend on the matplotlibrc file.  To get around that, 
another possibility would be to break pylab.py into two parts, with 
pylab.py continuing to do the namespace consolidation and importing the 
second part, which would contain the actual pylab functions.  Then if 
you don't want the namespace consolidation, you could simply import the 
second part instead of pylab.  There may be devils in the details, but 
it seems to me that this last alternative--splitting pylab.py--might 
make a number of people happier while having no adverse effects on 
everyone else.

Eric
> 
> 
> Thanks,
> Sebastian
> _______________________________________________
> Numpy-discussion mailing list
> Num...@sc...
> http://projects.scipy.org/mailman/listinfo/numpy-discussion