matplotlib-devel Mailing List for matplotlib

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> I fear that this "fix" will rather add to the general
    Norbert> confusion than lighten it. First doing "from ... import
    Norbert> *" and then reverting it partly really seems like a bad
    Norbert> idea. The cleaner solution would be to fix
    Norbert> Numeric/numarray in such a way that the replacement
    Norbert> min/max/round/... retain the complete original
    Norbert> functionality of the builtins only extending them to new
    Norbert> types.  Independent of pylab, there obviously is a bug in
    Norbert> the underlying libraries which should not be obscured but
    Norbert> 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

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.

I already hate the current situation as it is: Both, SciPy and matplotlib, are 
based upon Numeric/numarray, but then they change and extend its behaviour in 
subtle ways so that - in the end - the user is completely confused. If there 
is a bug or a missing feature in the array library, it should be fixed there. 
Having arrays behave similar but slightly different in SciPy, matplotlib and 
numarray/Numeric should be avoided by all means.

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>