Re: [Matplotlib-users] "from pylab import *" will no longer override min() and max()

[John H. <jdh...@ac...>]

>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:

    Norbert> Why not go one step higher and discuss the issue in
    Norbert> Numeric and numarray? It seems like a typical problem in
    Norbert> the python community that conflicts are not discussed and
    Norbert> decided centrally but instead everyone just does things
    Norbert> their way. The possibility to change and fix everything
    Norbert> by a wrapper module really causes a huge mess in the
    Norbert> various libraries...

I still believe that this is not a problem with Numeric or numarray
[1].  There is nothing to fix there in my opinion (Todd or Perry can
jump in here).  Those modules provide min/max/etc in their respective
mlab modules, which do exactly what they advertise: they provide
matlab functionality and matlab provides min/max with a different
signature than python's.  There is no problem as long as the user is
mindful of namespaces; there's a reason your mother always told you
never to do 'from somemodule import *'.  I tend to heed that advice,
with the one exception being pylab, in which I try to provide a
matlab-like environment where the symbols are all provided in a single
namespace.

Note also that matplotlib's numerix module is more than a simple
numarray/Numeric switcher because it *combines* symbols from all of
their respective submodules.  Eg from na_imports, which is where
matplotlib.numerix gets the numarray symbols from

    from numarray.linear_algebra.mlab import *
    from numarray import *
    import numarray.linear_algebra as LinearAlgebra
    import numarray.linear_algebra.mlab as MLab
    from numarray.linear_algebra import inverse, eigenvectors
    from numarray.convolve import convolve
    from numarray.fft import fft
    import numarray.random_array as RandomArray
    from numarray.numeric import nonzero

So we are taking names from a bunch of different namespaces and
pooling them in numerix, which is then pooled into pylab.  This is a
good thing for users who want a matlab-like environment, and who want
to be able to switch between Numeric and numarray w/o having to write
a bunch of conditional code to handle the different directory layouts,
but as we've observed can bite you if you are unaware that pylab is
providing matlab names rather than python names in some cases.

Perhaps I'm wrong, but I suspect that 1) Numeric developers would be
very reluctant to change a name that has been in the code base for
god-knows-how-long and thus would break lots of code, and 2) the
functions in MLab actually do exactly what they are designed to do and
are well advertised as such.  I for one would definitely be against a
change, because when I do MLab.min I want the matlab signature.

Basically the question is: when confronted with a name clash, should a
module prefer python over matlab.  Numeric.MLab rightly (I think)
chose to go with matlab names, but some disagree with this decision
(yes, you Fernando).  For pylab, which has its genesis in matlab
compatibility but serves a wider community that may not know or care
about matlab, it may be sensible to make a different choice.  In
brief, I don't think it is terribly confusing for Numeric.MLab to have
one policy that when confronting a name clash they go with the matlab
name, and for matplotlib.numerix have a different policy and say we'll
go with the built-in and provide the amin, amax, etc symbols for the
MLab versions.  Two different packages/modules can rightly have
different policies on how closely they want to abide by the matlab
names.

JDH


[1] http://sourceforge.net/mailarchive/message.php?msg_id=10514961