From: Andrew S. <str...@as...> - 2004-12-19 03:36:50
|
Here's something I find surprising (and disconcerting): astraw@flygate:~$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> min(1,2) 1 >>> from pylab import * >>> min(1,2) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/numarray/linear_algebra/mlab.py", line 149, in min return minimum.reduce(m,axis) ValueError: Empty array in a ufunc that has no identity value. So, it seems that the "min" function is overridden. Digging deeper, >>> min.__module__ 'numarray.linear_algebra.mlab' OK, I see what's going on here: in an effort to achieve maximum matlab compatibility, pylab imports everything (or at least min) from numarray.linear_algebra.mlab. The trouble with this is that a simple "from pylab import *" will break a script that uses min() on scalars. While numarray may have very good reasons for overriding builtins (although I admit that I cannot see what), I think causing normal Python scripts to break by simply importing pylab into their namespace is not the way to achieve total world domination. :) This may be a numarray.linear_algebra.mlab bug/issue and I should go to their mailing list. (Although here is probably as good a place to reach them :). But, even if the good numarray folks did it this way for a reason (I'd love to know, but I should hunt on their FAQ before asking), I suggest than pylab seek to not (incompatibly) override builtins. Again, "from pylab import *" is our plan for total world domination, and I suggest we not break pure Python scripts. The general problem does not appear serious: >>> from pylab import * >>> >>> for key in globals().keys(): ... if key in dir(__builtins__): ... print "'%s' was overridden."%key ... 'round' was overridden. 'sum' was overridden. 'abs' was overridden. 'max' was overridden. 'min' was overridden. '__doc__' was overridden. '__name__' was overridden. Cursory checks of the above functions indicate all except min(), max(), and round() are compatible with normal (non-exception raising) Python use. Even round() is apparently deprecated by numarray to around(). So, basically, I think we're just talking about min() and max(). What do folks think? |
From: Andrew S. <str...@as...> - 2005-01-08 00:38:37
|
A few weeks ago (on Dec 18), I send an email to the matplotlib-devel list indicating that "from pylab import *" overrides some builtin functions, such as min() and max(). [1] This results from pylab enlarging its namespace greatly with statements like "from numerix import *" and "from mlab import *". In general this is a good thing, but it seems numarray.linear_algebra.mlab (amongst possibly others) overrides some builtin names. Although I don't see the benefit in this design for numarray.linear_algebra.mlab, I can live with it, since I never do "from numarray.linear_algebra.mlab import *". However, I (and many others here, I suspect) would like to frequently use "from pylab import *", and it really pisses me off when I discover that various builtins are overridden, causing mysterious errors that may be hard to track down. So, I offer the following patch [2] to pylab.py which fixes this. I hereby ask for your feedback indicating if you are happy with the current behavior, or if you prefer that pylab does not override builtins. (Also, if you have a better way, that would be appreciated, too.) You may check your own systems using a little script I wrote while testing this. [3] Cheers! Andrew [1] http://sourceforge.net/mailarchive/forum.php?thread_id=6190717&forum_id=36187 [2] Patch to pylab.py, to be inserted anywhere after the last "from blah import *", e.g. line 216. # restore builtin functions which may have been overridden min = getattr(sys.modules['__builtin__'],'min') max = getattr(sys.modules['__builtin__'],'max') sum = getattr(sys.modules['__builtin__'],'sum') round = getattr(sys.modules['__builtin__'],'round') abs = getattr(sys.modules['__builtin__'],'abs') [3] Script to test for overriding of builtin names: import sys def check_globals(): for key in globals().keys(): if key in dir(sys.modules['__builtin__']): if globals()[key] != getattr(sys.modules['__builtin__'],key): print "'%s' was overridden in globals()."%key print 'before pylab import' check_globals() print from pylab import * print 'after pylab import' check_globals() print |
From: Fernando P. <Fer...@co...> - 2005-01-08 00:51:30
|
Andrew Straw wrote: > So, I offer the following patch [2] to pylab.py which fixes this. I > hereby ask for your feedback indicating if you are happy with the > current behavior, or if you prefer that pylab does not override > builtins. (Also, if you have a better way, that would be appreciated, too.) +1 on your patch. I'd also much rather have the builtin namespace be left alone. Cheers, f |
From: Norbert N. <Nor...@gm...> - 2005-01-09 19:08:52
|
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...> |
From: John H. <jdh...@ac...> - 2005-01-09 21:21:33
|
>>>>> "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 |
From: Fernando P. <Fer...@co...> - 2005-01-10 01:39:35
|
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 |
From: Perry G. <pe...@st...> - 2005-01-10 03:17:02
|
Fernando Perez wrote: > 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: > [...] My 2 cents is that I think Fernando is right on this issue. I'd rather go with a solution that causes temporary pain for matlab users rather than one that causes lingering, long-term irritations. Perry |
From: John H. <jdh...@ac...> - 2005-01-10 10:51:45
|
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> My 2 cents is that I think Fernando is right on this Perry> issue. I'd rather go with a solution that causes temporary Perry> pain for matlab users rather than one that causes Perry> lingering, long-term irritations. OK, looks like a consensus to me :-) I'm happy with Fernando's proposed names amin, amax, around, etc. If everyone else is too, I propose Andrew implement his patch, provide the compatibility names, and update the relevant docs to advertise this prominently: API_CHANGES, CHANGELOG, tutorial and users guide. Particularly in the latter two, I think we should warn people about the potential performance hit of using the builtin min, max and friends on large arrays. I'll put this on the new "News Flash" section of the web site with the next release, which at least should get people's attention. A-foolish-consistency-is-the-hobgobblin-of-a-small-mindly-yours, JDH |
From: Norbert N. <Nor...@gm...> - 2005-01-10 13:30:27
|
Am Montag, 10. Januar 2005 11:46 schrieb John Hunter: > I'm happy with Fernando's proposed names amin, amax, around, etc. If > everyone else is too, I propose Andrew implement his patch, provide > the compatibility names, and update the relevant docs to advertise > this prominently: API_CHANGES, CHANGELOG, tutorial and users guide. > Particularly in the latter two, I think we should warn people about > the potential performance hit of using the builtin min, max and > friends on large arrays. There might be a solution that avoids the performance hit: there should not be any problem with pylab offering an optimized set of min, max, etc. as long as their signature is identical to the builtins and the behavior only extends them. Something along the line of: def min(*args, **kwargs): if args == (): raise TypeError, "min() takes at least 1 argument (0 given)" if len(args) == 1 and type(args[0]) is ArrayType: axis=kwargs.pop('axis',0) res = minimum.reduce(args[0],axis) else: res = __builtin__.min(*args) if len(kwargs)>0: raise TypeError, ( "min() got an unexpected keyword argument '%s'" %kwargs.keys()[0] ) return res Probably, one could even avoid separate amin, amax, etc. functions. The user just has to be aware that the axis can only be given as keyword argument. -- _________________________________________Norbert Nemec Bernhardstr. 2 ... D-93053 Regensburg Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199 eMail: <No...@Ne...> |
From: Fernando P. <Fer...@co...> - 2005-01-10 19:49:20
|
Norbert Nemec wrote: > Am Montag, 10. Januar 2005 11:46 schrieb John Hunter: > >>I'm happy with Fernando's proposed names amin, amax, around, etc. If >>everyone else is too, I propose Andrew implement his patch, provide >>the compatibility names, and update the relevant docs to advertise >>this prominently: API_CHANGES, CHANGELOG, tutorial and users guide. >>Particularly in the latter two, I think we should warn people about >>the potential performance hit of using the builtin min, max and >>friends on large arrays. > > > There might be a solution that avoids the performance hit: there should not be > any problem with pylab offering an optimized set of min, max, etc. as long as > their signature is identical to the builtins and the behavior only extends > them. Something along the line of: Hmm. Those extra checks in your code don't come for free... I'd rather leave the builtins alone (many of them are C-coded, hence quite fast), and just provide array versions where needed. Just my 1e-2 Best, f |
From: Andrew S. <as...@ca...> - 2005-01-10 21:38:09
|
John Hunter wrote: >>>>>>"Perry" == Perry Greenfield <pe...@st...> writes: >>>>>> >>>>>> > > Perry> My 2 cents is that I think Fernando is right on this > Perry> issue. I'd rather go with a solution that causes temporary > Perry> pain for matlab users rather than one that causes > Perry> lingering, long-term irritations. > >OK, looks like a consensus to me :-) > > I guess my opinion on this is already clear :). >I'm happy with Fernando's proposed names amin, amax, around, etc. If >everyone else is too, I propose Andrew implement his patch, provide >the compatibility names, and update the relevant docs to advertise >this prominently: API_CHANGES, CHANGELOG, tutorial and users guide. >Particularly in the latter two, I think we should warn people about >the potential performance hit of using the builtin min, max and >friends on large arrays. > > I'm happy to implement whatever the consensus is, but I'm quite busy this week and away this weekend, so it'll be next week until I can do anything. If someone else wants to jump in and do it, I certainly won't mind. Norbert Nemec wrote: > There might be a solution that avoids the performance hit: there should not be > any problem with pylab offering an optimized set of min, max, etc. as long as > their signature is identical to the builtins and the behavior only extends > them. Something along the line of: > > def min(*args, **kwargs): > if args == (): > raise TypeError, "min() takes at least 1 argument (0 given)" > if len(args) == 1 and type(args[0]) is ArrayType: > axis=kwargs.pop('axis',0) > res = minimum.reduce(args[0],axis) > else: > res = __builtin__.min(*args) > if len(kwargs)>0: > raise TypeError, ( > "min() got an unexpected keyword argument '%s'" > %kwargs.keys()[0] > ) > return res What do people think about Norbert's "best of both worlds" approach? Although it seems great in theory, I'm disinclined to use it simply because it does override the builtin. Although he's doubtlessly constructed this with the greatest of care to perform exactly as the builtin, I wonder about obscure corner cases which won't behave exactly the same and may result in even more obscure bugs. Maybe my misgivings are undue paranoia on my part, and his 3rd way really is best. I suppose I'd want to throw lots of tests at it before I pronounce my final judgement on it, which I don't have time to do at the moment. (Next week, if need be...) Just a thought for consideration: perhaps Norbert's code could actually be used by the underlying mlab.py modules? I guess some code in the wild uses the axis argument not as a keyword, so there would be a backwards incompatible change in that regard... Other than that, though, this kind of behavior from the mlab.py modules would probably have resulted in a less serious conundrum than what we now face. Also, we must not forget about round, sum, and abs (and any others I have missed). For example, abs() caught me because I use the cgkit quaternion type, which overrides the __abs__ method and thus fails to work properly with the mlab.py implementation of abs(). Cheers! Andrew |
From: Norbert N. <Nor...@gm...> - 2005-01-11 09:14:28
|
OK, I understand that the overhead added by my routine is a bit much. Maybe, we could just go half-way? Overriding min and max for arrays, but leaving the axis-argument for more specialized amin and amax routines? Am Montag, 10. Januar 2005 22:38 schrieb Andrew Straw: > Also, we must not forget about round, sum, and abs (and any others I have > missed). For example, abs() caught me because I use the cgkit quaternion > type, which overrides the __abs__ method and thus fails to work properly > with the mlab.py implementation of abs(). Look at these one by one: * abs() already calls an __abs__() method. The clean way to extend it, would therefore be to give arrays such a method. This should solve the problem completely. * round() does not seem to be extendable in Python. Maybe we should propose to change Python itself to introduce a __round__ method? That would only be straightforward. * min, max and sum are all based on iterating over a sequence. Maybe, one should again have __min__, __max__ and __sum__ which should then be checked by the builtin before falling back to iterating over the sequence? I could imagine many kinds of containers that could optimize these operations. So this would again be a detail that should be changed in Python itself. If the builtin min() function would then also pass on keyword arguments, that would solve our problem completely and thoroughly. Does anybody have experience with discussions in the Python forum to estimate how realistic such a PEP would be? Ciao, Norbert -- _________________________________________Norbert Nemec Bernhardstr. 2 ... D-93053 Regensburg Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199 eMail: <No...@Ne...> |
From: Andrew S. <str...@as...> - 2005-01-10 21:39:26
|
John Hunter wrote: >>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: >>>>>> >>>>> > > Perry> My 2 cents is that I think Fernando is right on this > Perry> issue. I'd rather go with a solution that causes temporary > Perry> pain for matlab users rather than one that causes > Perry> lingering, long-term irritations. > > OK, looks like a consensus to me :-) > > I guess my opinion on this is already clear :). > I'm happy with Fernando's proposed names amin, amax, around, etc. If > everyone else is too, I propose Andrew implement his patch, provide > the compatibility names, and update the relevant docs to advertise > this prominently: API_CHANGES, CHANGELOG, tutorial and users guide. > Particularly in the latter two, I think we should warn people about > the potential performance hit of using the builtin min, max and > friends on large arrays. > > I'm happy to implement whatever the consensus is, but I'm quite busy this week and away this weekend, so it'll be next week until I can do anything. If someone else wants to jump in and do it, I certainly won't mind. Norbert Nemec wrote: > There might be a solution that avoids the performance hit: there > should not be any problem with pylab offering an optimized set of min, > max, etc. as long as their signature is identical to the builtins and > the behavior only extends them. Something along the line of: > > def min(*args, **kwargs): > if args == (): > raise TypeError, "min() takes at least 1 argument (0 given)" > if len(args) == 1 and type(args[0]) is ArrayType: > axis=kwargs.pop('axis',0) > res = minimum.reduce(args[0],axis) > else: > res = __builtin__.min(*args) > if len(kwargs)>0: > raise TypeError, ( > "min() got an unexpected keyword argument '%s'" > %kwargs.keys()[0] > ) > return res What do people think about Norbert's "best of both worlds" approach? Although it seems great in theory, I'm disinclined to use it simply because it does override the builtin. Although he's doubtlessly constructed this with the greatest of care to perform exactly as the builtin, I wonder about obscure corner cases which won't behave exactly the same and may result in even more obscure bugs. Maybe my misgivings are undue paranoia on my part, and his 3rd way really is best. I suppose I'd want to throw lots of tests at it before I pronounce my final judgement on it, which I don't have time to do at the moment. (Next week, if need be...) Just a thought for consideration: perhaps Norbert's code could actually be used by the underlying mlab.py modules? I guess some code in the wild uses the axis argument not as a keyword, so there would be a backwards incompatible change in that regard... Other than that, though, this kind of behavior from the mlab.py modules would probably have resulted in a less serious conundrum than what we now face. Also, we must not forget about round, sum, and abs (and any others I have missed). For example, abs() caught me because I use the cgkit quaternion type, which overrides the __abs__ method and thus fails to work properly with the mlab.py implementation of abs(). Cheers! Andrew |
From: John H. <jdh...@ac...> - 2005-01-10 11:28:50
|
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> I'm happy with Fernando's proposed names amin, amax, around, John> etc. If everyone else is too, I propose Andrew implement John> his patch, provide the compatibility names, and update the John> relevant docs to advertise this prominently: API_CHANGES, John> CHANGELOG, tutorial and users guide. Particularly in the John> latter two, I think we should warn people about the John> potential performance hit of using the builtin min, max and John> friends on large arrays. Hmm, another thought. If we are going to make this change for the pylab namespace, then it seems we might as well make the change in the numerix namespace as well, since all the same arguments apply. I think doing different things in numerix and pylab *is* a recipe for confusion. What do you think Todd, does this seem sensible? Basically, the theme would be we use the underlying names from Numeric/numarray except when they clash with python builtins, in which case we'd use something like the a* names Fernando proposed. Of course, changing the numerix names would mean the matplotlib code and examples will have to be updated as well. The former should be relatively easy since I believe there are no uses of unqualified min and max from numerix in the base code. Eg, we do in axes.py from numerix import max as nxmax from numerix import min as nxmin and in mlab.py we do MLab.max. But we'll have to be careful to make sure all the names Andrew identified are handled thoughout the coude and examples... JDH |
From: Perry G. <pe...@st...> - 2005-01-10 14:51:39
|
On Jan 10, 2005, at 6:23 AM, John Hunter wrote: >>>>>> "John" == John Hunter <jdh...@ac...> writes: > > John> I'm happy with Fernando's proposed names amin, amax, around, > John> etc. If everyone else is too, I propose Andrew implement > John> his patch, provide the compatibility names, and update the > John> relevant docs to advertise this prominently: API_CHANGES, > John> CHANGELOG, tutorial and users guide. Particularly in the > John> latter two, I think we should warn people about the > John> potential performance hit of using the builtin min, max and > John> friends on large arrays. > > Hmm, another thought. > > If we are going to make this change for the pylab namespace, then it > seems we might as well make the change in the numerix namespace as > well, since all the same arguments apply. I think doing different > things in numerix and pylab *is* a recipe for confusion. What do you > think Todd, does this seem sensible? > I can't argue with that (though Todd may have some comments of his own). In fact it would seem silly if numerix wasn't consistent. |
From: Todd M. <jm...@st...> - 2005-01-10 17:06:25
|
On Mon, 2005-01-10 at 06:23, John Hunter wrote: > >>>>> "John" == John Hunter <jdh...@ac...> writes: > > John> I'm happy with Fernando's proposed names amin, amax, around, > John> etc. If everyone else is too, I propose Andrew implement > John> his patch, provide the compatibility names, and update the > John> relevant docs to advertise this prominently: API_CHANGES, > John> CHANGELOG, tutorial and users guide. Particularly in the > John> latter two, I think we should warn people about the > John> potential performance hit of using the builtin min, max and > John> friends on large arrays. > > Hmm, another thought. > > If we are going to make this change for the pylab namespace, then it > seems we might as well make the change in the numerix namespace as > well, since all the same arguments apply. I think doing different > things in numerix and pylab *is* a recipe for confusion. What do you > think Todd, does this seem sensible? > > Basically, the theme would be we use the underlying names from > Numeric/numarray except when they clash with python builtins, in which > case we'd use something like the a* names Fernando proposed. > > Of course, changing the numerix names would mean the matplotlib code > and examples will have to be updated as well. The former should be > relatively easy since I believe there are no uses of unqualified min > and max from numerix in the base code. Eg, we do in axes.py > > from numerix import max as nxmax > from numerix import min as nxmin > > and in mlab.py we do MLab.max. But we'll have to be careful to make > sure all the names Andrew identified are handled thoughout the coude > and examples... > > JDH This all sounds fine to me. My understanding is that anywhere we "get this wrong" the impact will be degraded performance. As an aside, I avoid "from *" like the plague myself but understand that it's important to optimize interactive use. Unleash Andrew and I'll try to propagate the changes forward to Scipy. Todd |