rant against from numpy import * / from pylab import *
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 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 ? Thanks, Sebastian
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@scipy.org 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@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
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@hawaii.edu> 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
Sebastian Haase wrote: 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@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (2)
-
Eric Firing -
Sebastian Haase