From: Andrew S. <str...@as...> - 2005-01-19 22:33:35
|
I've just committed a patch to stop "from pylab import *" from overriding Python builtin functions like min() and max(). Spurred on by the potential of matplotlib included in the Enthought Edition of Python, I've gone ahead and added the following lines to pylab.py in CVS: import __builtin__ min = __builtin__.min max = __builtin__.max sum = __builtin__.sum round = __builtin__.round abs = __builtin__.abs Although I didn't do anything about it, and without having thought about it deeply, I like Norbert Nemec's idea of introducing __round__ (and __min__, __max__, and __sum__ for sequences) methods into standard Python, thus eliminating the need for functions in numpy/numarray to accomplish these same tasks. Unfortunately, I don't have the time to get into this right now. (This approach would also ask numpy/numarray to eliminate their abs() function in favor of implementing an __abs__() method on array types.) Cheers! Andrew |
From: Norbert N. <No...@ne...> - 2005-01-20 08:30:44
|
Am Mittwoch, 19. Januar 2005 23:39 schrieb John Hunter: > I thought we last left this with the idea that these changes would be > made in matplotlib.numerix level Why not go one step higher and discuss the issue in Numeric and numarray? It seems like a typical problem in the python community that conflicts are not discussed and decided centrally but instead everyone just does things their way. The possibility to change and fix everything by a wrapper module really causes a huge mess in the various libraries... -- _________________________________________Norbert Nemec Bernhardstr. 2 ... D-93053 Regensburg Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199 eMail: <Norbert@Nemec-online.de> |
From: John H. <jdh...@ac...> - 2005-01-20 14:33:54
|
>>>>> "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 |
From: Todd M. <jm...@st...> - 2005-01-20 15:27:50
|
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 |
From: Norbert N. <Nor...@gm...> - 2005-01-22 12:20:30
|
Maybe, the situation could be somewhat relaxed by uncluttering pylab: Currently, pylab.py does two things: * give a stateful matlab like interface to the object-oriented matplotlib plotting library * pull together all kinds of namespaces. What about pulling all the plotting routines into a separate file that can be included by anyone who just wants the comfortable plotting commands without all the other namespace cluttering. pylab itself would then only contain lots of imports and all the namespace mangling. For me personally, this would be the solution. I use matplotlib for plotting only and for my purpose , simple plotting interface from pylab is much nicer than the full object oriented interface. For numerics, however, I would prefer to go as pythonic as possible without any compromises for matlab similarity. Cleanly dividing the two purposes of matplotlib (nice plotting and matlab similarity) would certainly help matters. -- _________________________________________Norbert Nemec Bernhardstr. 2 ... D-93053 Regensburg Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199 eMail: <Norbert@Nemec-online.de> |
From: John H. <jdh...@ac...> - 2005-01-24 15:15:55
|
>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes: Norbert> What about pulling all the plotting routines into a Norbert> separate file that can be included by anyone who just Norbert> wants the comfortable plotting commands without all the Norbert> other namespace cluttering. pylab itself would then only Norbert> contain lots of imports and all the namespace mangling. I think this is a good idea, especially since is a natural way to do it with the existing organization that shouldn't break much code. We already have the two modules in place: matplotlib.pylab and pylab. The former would just export the plotting symbols defined therein and the latter would be the namespace aggregator. Thus pylab.__all__ would be just as it is with 0.71 (plotting, numerix, mlab, matplotlib.dates symbols, matplotlib.ticker symbols, some colormapping stuff) and matplotlib.pylab.__all__ would only be the plotting commands. Scripts which currently do from pylab import * would be unaffected. There are some scripts which would be affected by these changes for those who eschew 'import *'. If you are getting the DateFormatter from pylab, you'll have to get it from matplotlib.dates instead. Basically, this would primarily affect people who are using custom tick locators or date locators/formatters. Of course, matplotlib.pylab *could* continue to provide these, but that seems to defeat the purpose of the change, which is to be more rigorous about exported namespaces. So the two questions are: 1) are people in favor of this change? and 2) if so, what should matplotlib.pylab export? Only symbols defined therein? Or perhaps add a few for backward compatibility? Specifically I'm wondering if matplotlib.pylab should continue to export: cm.jet, cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and *Formatter symbols from matplotlib.ticker and matplotlib.dates? I don't suppose it's possible to "warn on import", eg warning "matplotlib.pylab import of date2num is deprecated, please use matplotlib.dates instead". One could write wrappers for this, I know, but is there some import wizardry which supports this? JDH |
From: Norbert N. <Nor...@gm...> - 2005-01-24 15:57:36
|
Am Montag, 24. Januar 2005 16:09 schrieb John Hunter: > >>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes: > > Norbert> What about pulling all the plotting routines into a > Norbert> separate file that can be included by anyone who just > Norbert> wants the comfortable plotting commands without all the > Norbert> other namespace cluttering. pylab itself would then only > Norbert> contain lots of imports and all the namespace mangling. > > I think this is a good idea, especially since is a natural way to do > it with the existing organization that shouldn't break much code. We > already have the two modules in place: matplotlib.pylab and pylab. > The former would just export the plotting symbols defined therein and > the latter would be the namespace aggregator. Don't know, whether it is a good idea to make a distinction between pylab and matplotlib.pylab - It would be clearer to create a new module (maybe matplotlib.plotting, matplotlib.pyplot or whatever) and move all routines from pylab to that new module. That would make clear: the term 'pylab' stands for the idea to create an environment that is as similar as possible to matlab. For the question what the new module should contain: only a small, clear-cut set of routines. A regular module should only export what it defines itself. Re-exporting blurs the modularity of the library and makes it harder to understand. Ciao, Norbert -- _________________________________________Norbert Nemec Bernhardstr. 2 ... D-93053 Regensburg Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199 eMail: <Norbert@Nemec-online.de> |
From: Perry G. <pe...@st...> - 2005-01-24 18:44:31
|
On Jan 24, 2005, at 10:09 AM, John Hunter wrote: > So the two questions are: 1) are people in favor of this change? and I haven't given lengthy thought, but yes, I think it is probably a good idea. The only counterargument is that something like making them available in pylab is that it guards a bit against possible reorganization of the modules and could potentially shield users against that. One view of pylab is that it provides a more stable interface to what is underneath. If there are items that are pretty fixed in their design, perhaps they belong (here or in another related module) > 2) if so, what should matplotlib.pylab export? Only symbols defined > therein? Or perhaps add a few for backward compatibility? > Specifically > I'm wondering if matplotlib.pylab should continue to export: cm.jet, > cm.gray, etc, date2num, num2date, drange, and perhaps the *Locator and > *Formatter symbols from matplotlib.ticker and matplotlib.dates? I > don't suppose it's possible to "warn on import", eg warning > "matplotlib.pylab import of date2num is deprecated, please use > matplotlib.dates instead". One could write wrappers for this, I know, > but is there some import wizardry which supports this? > I think one could overload the import mechanism to handle this, but I'm thinking that it is probably not worth the downside of messing with the import mechanism. Perry |
From: Chris B. <Chr...@no...> - 2005-01-20 17:42:40
|
As long as this is being discussed, I'll put in my $0.2 I think encouraging "import *" Is a BAD IDEA. Even for interactive use. Since I've used Python, the only time I've used import * is for Numeric, and now I've started using import Numeric as N. > Namespaces are one honking great idea -- let's do more of those! That's why I'm resistant to using import * Anyway, I'm very happy about matplotlib because it does most of what I need, does it well, works with wx and AGG, and is constantly being improved. However, even though I'm an old matlab fanatic, I'm not thrilled with the efforts to make matplotlib matlab-like. I have various reasons for using Python rather than matlab, but one of the primary ones is that I like the language better, and I like OO. Hence, I'd much rather have a platting package be pythonic than matlab-like. Name spaces and OO are a big part of this. Name spaces and an OO interface are very linked, by the way. The reason NumPy is commonly used with the import * approach is that there are a LOT of functions exposed, and we all get tired of typing Numeric. (or even N.). However, many of those functions should really be methods. I've always been confused by the Numeric docs, which suggest that the function interface is necessary so that you can do, for instance: B = Numeric.transpose(A) and A doesn't have to be a Numeric Array. This would be very cool if transpose (and many other ufuncs) returned the type that was input, but it doesn't, it returns an array, so it's really the equivalent of: B = array(A) B.transpose(B) if transpose were an array method. Is it really so onerous to type that extra line? I like the extra line, because it makes things clear to me what's going on. anyway, to cut my rant short, here is my vote for matplotlib development (not that I get a vote, but hopefully I'll have time to help out someday) 1) Deprecate "from pylab import *" 2) Improve the OO interface to make it just as easy to use. Even with improvements, I understand that it will be a little bit more awkward to use in interactive mode, but how much does anyone really do interactively anyway? Even with Matlab, I soon learned that if I'm typing more that 3 lines, I should put it in a script. I know we can do (2) without doing (1), but if (1) is what's in all the examples, it's going to get used. OK, enough of my rant. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: John H. <jdh...@ac...> - 2005-01-27 14:57:25
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> anyway, to cut my rant short, here is my vote for Chris> matplotlib development (not that I get a vote, but Chris> hopefully I'll have time to help out someday) Hey, I live in Chicago -- we pioneered "vote early, vote often". Chris> 2) Improve the OO interface to make it just as easy to use. Do you have some suggestions which would make the OO interface easier to use? For concreteness, here is the archetypal OO script from matplotlib.backends.backend_svg import FigureCanvasSVG from matplotlib.figure import Figure fig = Figure() ax = fig.add_subplot(211) ax.plot([1,2,3]) ax.set_xlabel('time') canvas = FigureCanvasSVG(fig) canvas.print_figure('myfile.svg') Things that leap to my mind: * hide the complexity of having both a canvas and the figure from the user, allowing them to deal only with figures, or at least have the figure store a ref to its canvas and allow you to do fig.savefig('myfig') which can forward the call on to its canvas print_figure method. This would bring the OO interface closer to the pylab interface and would prevent you from having to remember which methods were fig methods and which methods were canvas methods. We could also provide a pylab independent factory function that instantiates a figure and canvas with the relevant initialization, allowing you to do something like fig, canvas = figure_factory(*args, **kwargs) # use the current backend but I'm not sure how advisable it is to hide this complexity because what you ultimately do with the objects depends on whether you are using a GUI backend or not. But for pure image backends it would be possible to have a single OO interface which works across backends. * move the (few) remaining pylab only methods (axis, colorbar) into the OO framework for full compatibility * use properties/traits so you could do ax.xlabel = 'hi mom' while retaining the setters and getters for backwards compatibility * provide more pure OO examples in the examples directory * significant;y expand the OO section of the user's guide Do you have additional ideas? Or are these the issues your were thinking of? JDH |
From: Andrew S. <str...@as...> - 2005-01-20 20:41:12
|
OK, let's get this straight. The situation as it stands: Currently in CVS is an implementation such that "from pylab import *" does not override builtins. I think we all agree that this is the right behavior. The question is now the implementation. (The code I checked in simply restores of pylab's names to the builtins. e.g. in the pylab.py: "min = __builtin__.min") John suggests moving my "solution" (I prefer to think of it as a band-aid, curing the symptom, but not the cause) up the chain to numerix, such that numerix.min = __builtin__.min (same for max, etc). Additionally, he suggests bringing a few more names into existence such that numerix.nxmin = mlab.min (same again for max, etc). I have no problem with this, but Todd "we should keep numerix compatible with Numeric" Miller does, and I can see he has a valid point. Thus, I see no easy resolution which is of little consequence to those of us who do not use numerix in our code. Since I am personally quite busy with other stuff, and I don't see a clear consensus of this numerix issue, which is secondary to my initial gripe regarding pylab. I am disinclined to do anything more at this point. I will hereby let someone who cares more than I do about numerix take it from here. For the record, I agree with everyone that "from blah import *" is a bad idea. However, pylab is special and thus deserves special attention. Partly this is because John, Fernando, and others have spent many hours making sure it plays well in IPython, resulting in IPython's pylab mode being the best Python interactive scientific plotting solution. Personally, I agree with Fernando's decision to do a "from pylab import *" in ipython -pylab because it enables rapid, interactive data exploration. (Besides which, it freakin' rocks!! :) Given ipython -pylab is my most frequently used interactive Python, I want min/max/etc to be the builtin functions (especially since I tend to do "run -i blah.py" from IPython a lot, which thus inherit names, including min and max, from ipython's interactive namespace). Also, I am still intrigued by Norbert's suggestion to change Python itself to eliminate this mess, but I don't have the time to deal with it. Furthermore, even if someone did step up to the plate, this is a longer term solution, and we'd still need a "band-aid" for the immediate term. Getting back to my day job now, Andrew |
From: Todd M. <jm...@st...> - 2005-01-20 22:14:02
|
Sorry Andrew. I wasn't paying careful enough attention to what John was saying and have a different idea of what numerix should evolve into: a simple numarray/Numeric switcher which provides "normalized" access to the standard packages. If multiple namespaces are combined, that's OK as long as we don't inject new behavior which defeats numerix's role as a Numeric replacement. In the general sense, the purpose of numerix is to make Numeric software available for numarray users. Fairly soon I think we're going to want to factor it out of matplotlib and use it in other places. I agree with John that numerix is not completely a simple switcher now, but I think that's where it needs to head. Whatever short term solution is chosen for min,max,etc... isn't that big a deal. Regards, Todd On Thu, 2005-01-20 at 15:41, Andrew Straw wrote: > OK, let's get this straight. The situation as it stands: > > Currently in CVS is an implementation such that "from pylab import *" > does not override builtins. I think we all agree that this is the right > behavior. The question is now the implementation. (The code I checked > in simply restores of pylab's names to the builtins. e.g. in the > pylab.py: "min = __builtin__.min") > > John suggests moving my "solution" (I prefer to think of it as a > band-aid, curing the symptom, but not the cause) up the chain to > numerix, such that numerix.min = __builtin__.min (same for max, etc). > Additionally, he suggests bringing a few more names into existence such > that numerix.nxmin = mlab.min (same again for max, etc). I have no > problem with this, but Todd "we should keep numerix compatible with > Numeric" Miller does, and I can see he has a valid point. Thus, I see > no easy resolution which is of little consequence to those of us who do > not use numerix in our code. > > Since I am personally quite busy with other stuff, and I don't see a > clear consensus of this numerix issue, which is secondary to my initial > gripe regarding pylab. I am disinclined to do anything more at this > point. I will hereby let someone who cares more than I do about numerix > take it from here. > > For the record, I agree with everyone that "from blah import *" is a bad > idea. However, pylab is special and thus deserves special attention. > Partly this is because John, Fernando, and others have spent many hours > making sure it plays well in IPython, resulting in IPython's pylab mode > being the best Python interactive scientific plotting solution. > Personally, I agree with Fernando's decision to do a "from pylab import > *" in ipython -pylab because it enables rapid, interactive data > exploration. (Besides which, it freakin' rocks!! :) > > Given ipython -pylab is my most frequently used interactive Python, I > want min/max/etc to be the builtin functions (especially since I tend to > do "run -i blah.py" from IPython a lot, which thus inherit names, > including min and max, from ipython's interactive namespace). > > Also, I am still intrigued by Norbert's suggestion to change Python > itself to eliminate this mess, but I don't have the time to deal with > it. Furthermore, even if someone did step up to the plate, this is a > longer term solution, and we'd still need a "band-aid" for the immediate > term. > > Getting back to my day job now, > Andrew |
From: John H. <jdh...@ac...> - 2005-01-19 22:45:27
|
>>>>> "Andrew" == Andrew Straw <str...@as...> writes: Andrew> I've just committed a patch to stop "from pylab import *" Andrew> from overriding Python builtin functions like min() and Andrew> max(). Andrew> Spurred on by the potential of matplotlib included in the Andrew> Enthought Edition of Python, I've gone ahead and added the Andrew> following lines to pylab.py in CVS: Andrew> import __builtin__ min = __builtin__.min max = Andrew> __builtin__.max sum = __builtin__.sum round = Andrew> __builtin__.round abs = __builtin__.abs I thought we last left this with the idea that these changes would be made in matplotlib.numerix level, and that the old symbols would still be provided under the names amin, amax, aabs, etc..., and the existing matplotlib code and examples would be ported to the new naming scheme. Eg, http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187 My fear is that if we do this in pylab but not numerix, confusion will only deepen. FYI, we have until late Thursday I think to get anything we want in before the final enthon roll-up. JDH |
From: danny s. <dan...@ya...> - 2005-01-19 23:03:41
|
my comments on modules being exposed appear to have fallen into a vacuum. I still ask if "from matplotlib import *" should expose the time module or the sys module? Danny --- John Hunter <jdh...@ac...> wrote: > >>>>> "Andrew" == Andrew Straw <str...@as...> writes: > > Andrew> I've just committed a patch to stop "from pylab import *" > Andrew> from overriding Python builtin functions like min() and > Andrew> max(). > > Andrew> Spurred on by the potential of matplotlib included in the > Andrew> Enthought Edition of Python, I've gone ahead and added > the > Andrew> following lines to pylab.py in CVS: > > Andrew> import __builtin__ min = __builtin__.min max = > Andrew> __builtin__.max sum = __builtin__.sum round = > Andrew> __builtin__.round abs = __builtin__.abs > > > I thought we last left this with the idea that these changes would be > made in matplotlib.numerix level, and that the old symbols would > still > be provided under the names amin, amax, aabs, etc..., and the > existing > matplotlib code and examples would be ported to the new naming > scheme. > Eg, > http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187 > > My fear is that if we do this in pylab but not numerix, confusion > will > only deepen. > > FYI, we have until late Thursday I think to get anything we want in > before the final enthon roll-up. > > JDH > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive > Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, > etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 |
From: John H. <jdh...@ac...> - 2005-01-22 03:53:47
|
>>>>> "danny" == danny shevitz <dan...@ya...> writes: danny> my comments on modules being exposed appear to have fallen danny> into a vacuum. I still ask if "from matplotlib import *" danny> should expose the time module or the sys module? Hi Danny, Apparently your voice has escaped the void! I added the __all__ attribute to the pylab module to restrict the symbols it exports strictly to matplotlib and numerix symbols, which should protect you from these kids of unexpected effects. Cheers, JDH |