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