[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
Numpy-discussion@...177...
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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@...202...> 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

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@...202...> 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@...177...
http://projects.scipy.org/mailman/listinfo/numpy-discussion