[Numpy-discussion] rant against from numpy import * / from pylab import *

[Eric Firing]

Sebastian,

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.

Eric

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
>     matplotlib.use('WXAgg')
>     from  matplotlib import pylab
>     P = new.module("pylab_sparse","""pylab module minus stuff alreay
> in numpy""")
>     for k,v in pylab.__dict__.iteritems():
>         try:
>            if v is N.__dict__[k]:
>                continue
>         except KeyError:
>            pass
>         P.__dict__[k] = v
> 
>     P.ion()
>     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)
> 
> Thanks
> -Sebastian
> 
> 
> On 3/16/07, Eric Firing <efiring at hawaii.edu> wrote:
>> 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
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion