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 <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
