I fear that this "fix" will rather add to the general
> confusion than lighten it. First doing "from ... import
> *" and then reverting it partly really seems like a bad
> idea. The cleaner solution would be to fix
> Numeric/numarray in such a way that the replacement
> min/max/round/... retain the complete original
> functionality of the builtins only extending them to new
> types. Independent of pylab, there obviously is a bug in
> the underlying libraries which should not be obscured but
> solved.
This is not a bug in either matplotlib, Numeric or numarray. The min
and max in question were originally defined in Numeric's MLab module.
If you read that module's docstring
Matlab(tm) compatibility functions.
This will hopefully become a complete set of the basic functions available in
matlab. The syntax is kept as close to the matlab syntax as possible.
So the functions in question were explicitly designed to be compatible
with matlab, not python. The pylab interface of matplotlib was
designed to "finish the job" that MLab started, and extend the matlab
compatibility into the plotting arena, which is does quite faithfully.
Hence the pylab module imports the MLab symbols /
numarray.linear_algebra.mlab.
Because python handles namespaces well, there is no problem with MLab
defining a min with a different call syntax than the built-in. The
informed user can choose between them by avoiding the 'from MLab
import *' or 'from pylab import *' and using namespaces instead, eg
MLab.min or pylab.min.
In an effort to provide a matlab compatible environment, I have
encouraged the use of 'from pylab import *', which like matlab gives
you everything at your fingertips. Mainly this is for convenience to
the newbie and interactive user, who doesn't want to have to sort out
where all the symbols are. If you take a quick look at na_imports,
which imports the numarray symbols for matploltib.numerix, you'll see
this is nontrivial, with functions coming from a handful of different
places.
So I feel the current situation is reasonably coherent: pylab provides
matlab compatible functions. That said, I agree this is a problem,
and part of the migration from matplotlib.matlab to matplotlib.pylab
is made with the sense that this is ultimately a *python* library that
strives for matlab compatibility but not at all costs. I myself have
been bitten by the min/max confusion on more than one occasion, as
have other mpl developers.
So I see the merits of Andrew's proposal. If adopted, we should
provide nxmin, nxmax, nxround, etc in the pylab namespace and
advertise the changes widely in API_CHANGES, the CHANGELOG, the
tutorial and user's guide. We should be mindful that changing the
current behavior probably will break some mpl scripts and can result
in a *substantial* performance hit for users who use min and max in
place of nxmin and nxmax for numerix arrays because those functions
rely on the python sequence protocol. This was the source of a
considerable performance hit in the colormapping that was recently
fixed.
So newbies and naive users are going to get screwed one way or the
other. If we retain MLab.min, people who expect the python min will
sometimes get a signature error. If we instead provide nxmin, they'll
inadvertently take a performance hit if they use python min naively.
I'm weakly inclined to leave the situation as it is: it's compatible
with matlab which is essentially the pylab mission, and it's worked
for 10 or so years for Numeric's MLab. Cautious users and power users
have a clear alternative. If we leave it as in, we can easily provide
pymin, pymax, pyround, etc, for users who want the python version. I
am open to the proposal, but I think we should frame the argument as
one of performance versus convenience versus
least-likely-to-bite-your-ass versus matlab-compatibility rather than
fixing a bug.
JDH