[Numpy-discussion] rant against from numpy import * / from pylab import *
efiring at hawaii.edu
Thu Aug 9 14:12:00 EDT 2007
I am trying to move things in the direction of simpler and cleaner
namespaces, but I think that to do it well requires a systematic
approach to the continuing numpification of mpl, so I have been working
on mlab.py before tackling pylab. I hope everything can be done via
reorganization, without requiring any import tricks, but that remains to
be seen. I'm sorry this is taking a long time, but it is in the works.
Sebastian Haase wrote:
> Hi all,
> Here a quick update:
> I'm trying to have a concise / sparse module with containing only
> pylab-specific names and not all names I already have in numpy.
> To easy typing I want to call numpy "N" and my pylab "P".
> I'm now using this code:
> <code snipplet for importing matplotlib>
> import matplotlib, new
> from matplotlib import pylab
> P = new.module("pylab_sparse","""pylab module minus stuff alreay
> in numpy""")
> for k,v in pylab.__dict__.iteritems():
> if v is N.__dict__[k]:
> except KeyError:
> P.__dict__[k] = v
> del matplotlib, new, pylab
> </code sniplet for importing matplotlib>
> The result is "some" reduction in the number of non-pylab-specific
> names in my "P"-module. However there seem to be still many extra
> names left, like e.g.:
> alltrue, amax, array, ...
> look at this:
> # 20070802
> # >>> len(dir(pylab))
> # 441
> # >>> len(dir(P))
> # 346
> # >>> P.nx.numpy.__version__
> # '1.0.1'
> # >>> N.__version__
> # '1.0.1'
> # >>> N.alltrue
> # <function alltrue at 0x01471B70>
> # >>> P.alltrue
> # <function alltrue at 0x019142F0>
> # >>> N.alltrue.__doc__
> # 'Perform a logical_and over the given axis.'
> # >>> P.alltrue.__doc__
> # >>> #N.alltrue(x, axis=None, out=None)
> # >>> #P.alltrue(x, axis=0)
> I'm using matplotlib with
> __version__ = '0.90.0'
> __revision__ = '$Revision: 3003 $'
> __date__ = '$Date: 2007-02-06 22:24:06 -0500 (Tue, 06 Feb 2007) $'
> Any hint how to further reduce the number of names in "P" ?
> My ideal would be that the "P" module (short for pylab) would only
> contain the stuff described in the __doc__ strings of `pylab.py` and
> `__init__.py`(in matplotlib) (+ plus some extra, undocumented, yet
> pylab specific things)
> On 3/16/07, Eric Firing <efiring at hawaii.edu> wrote:
>> Sebastian Haase wrote:
>>> 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)
>>> 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.
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
More information about the NumPy-Discussion