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

[Todd M. <jm...@st...>]

On Thu, 2005-01-20 at 09:28, John Hunter wrote:
> >>>>> "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. 

I agree with this;  pylab has a very clear "right" to choose whatever
API semantics it wants.  It occurs to me now that numerix probably needs
to evolve away from MLab back to pure Numeric,  but that has nothing to
do with the pylab API which can remain as it is.

I agree that overriding builtins is a mistake,  but I think we're in a
bind here.

[snip]

> 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,

This is my position as well:  Don't use from *.  Using it opens you up
to new names appearing in your module namespace based on changes outside
the module;  using it non-interactively is an engineering error. 

[snip]

> 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.

I have a strong aversion to breaking Numeric compatibility,  so I need
to reverse my earlier "unleash Andrew" comment and we should keep
numerix compatible with Numeric.

[snip]

> MLab versions.  Two different packages/modules can rightly have
> different policies on how closely they want to abide by the matlab
> names.

I agree.  That's why Python has namespaces.

IMHO, this boils down to choosing the lesser of two evils,  so if we're
talking about breaking APIs in the name of purity or remaining
compatible with Numeric but a little impure,  I'd prefer compatible.  My
$.02

Cheers,
Todd