Re: [matplotlib-devel] overridding builtin variables in pylab

[Fernando P. <Fer...@co...>]

John Hunter wrote:

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

While pylab's mission is indeed is matlab compatibility, you already point out 
that this is not an 'at all costs' objective.  This is one case where I really 
think that breaking compatibility with the base python language is a too high 
price to pay.  I'm having a hard time justifying my position in a clear 
manner, but I have a strong 'gut feeling' about it.  I'll try to provide some 
rational points, though:

One of pylab's, objectives is to help matlab users move over to python.  While 
initially they will naturally only use the compatible functions, we hope they 
will grow out into using all the things python offers which matlab lacks (nice 
OO, listcomps, generator expressions, the great generic standard library, 
etc.).  This means that ultimately, we hope they will really use the python 
language to its fullest.  At that point, if they begin using pyton code from 
'the wild', they are very likely to be bitten by this kind of incompatibility 
(as we all have).

The result: a decision made to ease the initial stages of a transition, ends 
up causing an everlasting headache.  And it's not like we can guarantee 100% 
source compatibility, since they are after all different languages.  I think 
it's much better to add min, max & friends to the few things matlab users need 
to learn in the transition, rather than have everyone pay for this from now on.

You also need to keep in mind that pylab is likely to be used by _python 
users_ who have no matlab experience (I am such a person).  For this group, 
the change of a builtin in this manner is very unexpected, and the source of 
all sorts of problems.  As anecdotal evidence, it was precisely this 
particular problem with MLab which convinced me, a few years ago, to _never_ 
use 'from foo import *'.  Even though I was not a matlab user, I thought the 
MLab names were nice and short, and for a while imported it wholesale.  Until 
I wasted a lot of time tracking the min/max bug one day.  When I found it, I 
felt like screaming at the MLab writers, and decided never again to trust a 
third party library with a * import.  To this day, I use Numeric and Scipy 
always with qualified imports.

IMHO, MLab simply got this one wrong 10 years ago, and pylab should not repeat 
their mistake.  In my own code, I have often written simple a* routines: amap, 
amin, amax, around, short for arraymap, arraymin, etc.  I think it's short and 
clear, and provides a nice distinction of their functionality versus the 
builtins (it's quicker to type amin than nxmin, esp. on a qwerty keyboard 
where nx is an off-home-row chord).

Anyway, this is as much as I'll say on the topic.  It's ultimately your 
choice.  But if I had my way, pylab would just provide a set of a*foo routines 
as array-based counterparts to the builtins, and it would document such a 
feature very prominently.

Cheers,

f