From: John G. <jn...@eu...> - 2005-05-18 11:22:21
|
In python 2.4 set is available as a built-in type. Now if I do: from pylab import * I get a function called set, which I can use to set properties on pylab objects. I'm wondering if set is now a bad name for pylab to be using? John |
From: Tim L. <ti...@cs...> - 2005-05-18 12:37:09
|
On Wed, 18 May 2005, John Gill <jn...@eu...> wrote... > In python 2.4 set is available as a built-in type. > > Now if I do: > > from pylab import * > > I get a function called set, which I can use to set properties on pylab > objects. > > I'm wondering if set is now a bad name for pylab to be using? +1 for changing it. I've also had this issue bite me when I was hacking together some code and wanted to use a python set. I'd be in favour of changing the pylab set to be called something else, although I don't have any good suggestions about what to change it to... Tim > > John `- |
From: John H. <jdh...@ac...> - 2005-05-18 14:23:18
|
>>>>> "Tim" == Tim Leslie <ti...@cs...> writes: >> I'm wondering if set is now a bad name for pylab to be using? Tim> +1 for changing it. Tim> I've also had this issue bite me when I was hacking together Tim> some code and wanted to use a python set. I'd be in favour of Tim> changing the pylab set to be called something else, although Tim> I don't have any good suggestions about what to change it Tim> to... Ouch, I hadn't thought of this. In the past, consensus has been that pylab should not override built-ins, eg the previous discussion on min/max which led us to rename these functions to amin/amax. Changing set, unfortunately, will break a lot of scripts. I think the best plan of action is to define a new function pset or setp (setp for "set property") which has the functionality of the old, and keep set around for a release or two issuing a warning with a line number so people can get their existing scripts cleaned up. JDH |
From: Tim L. <ti...@cs...> - 2005-05-18 14:44:37
|
On Wed, 18 May 2005, John Hunter <jdh...@ac...> wrote... > >>>>> "Tim" =3D=3D Tim Leslie <ti...@cs...> writes: > >> I'm wondering if set is now a bad name for pylab to be using? >=20 > Tim> +1 for changing it. >=20 > Tim> I've also had this issue bite me when I was hacking together > Tim> some code and wanted to use a python set. I'd be in favour of > Tim> changing the pylab set to be called something else, although > Tim> I don't have any good suggestions about what to change it > Tim> to... >=20 > Ouch, I hadn't thought of this. In the past, consensus has been that > pylab should not override built-ins, eg the previous discussion on > min/max which led us to rename these functions to amin/amax. Changing > set, unfortunately, will break a lot of scripts. I think the best > plan of action is to define a new function pset or setp (setp for "set > property") which has the functionality of the old, and keep set around > for a release or two issuing a warning with a line number so people > can get their existing scripts cleaned up. This sounds like a perfectly valid course of action to me. In the meantime, if people want to have set refer to python sets and setp refer=20 to the pylab set function the following should work (untested): =66rom pylab import * setp =3D set set =3D __builtins__.set Tim >=20 > JDH >=20 `- |
From: Fernando P. <Fer...@co...> - 2005-05-18 16:38:14
|
John Hunter wrote: >>>>>>"Tim" == Tim Leslie <ti...@cs...> writes: > > >> I'm wondering if set is now a bad name for pylab to be using? > > Tim> +1 for changing it. > > Tim> I've also had this issue bite me when I was hacking together > Tim> some code and wanted to use a python set. I'd be in favour of > Tim> changing the pylab set to be called something else, although > Tim> I don't have any good suggestions about what to change it > Tim> to... > > Ouch, I hadn't thought of this. In the past, consensus has been that > pylab should not override built-ins, eg the previous discussion on > min/max which led us to rename these functions to amin/amax. Changing > set, unfortunately, will break a lot of scripts. I think the best > plan of action is to define a new function pset or setp (setp for "set > property") which has the functionality of the old, and keep set around > for a release or two issuing a warning with a line number so people > can get their existing scripts cleaned up. I'd also suggest removing from all example code 'from pylab import *' statements. Frankly, after a while I've completely stopped using 'from foo import *' in _any_ code I write, even small scripts. All I use these days is code like: import Numeric as N import scipy as S import pylab as P The only place where I think that from-import-* is OK is at an interactive prompt, where you are just doing experiments and not writing reusable code. Since the examples tend to be the place that people learn from, I think it would be a good idea to encourage safer practices by banning the dangerous import-* idiom from there. Just my opinion. Best, f |
From: Chris B. <Chr...@no...> - 2005-05-19 21:32:49
|
Fernando Perez wrote: > I'd also suggest removing from all example code 'from pylab import *' > statements. Here here! (hear hear?). I'd really like to see all those "import *"'s go away. One way to get there is to add much of the functionality of pylab to the OO interface. I really wish I had the time to write an OO-pylab, I think it would be really great, even for interactive use. -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-05-23 15:03:59
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> Fernando Perez wrote: >> I'd also suggest removing from all example code 'from pylab >> import *' statements. Chris> Here here! (hear hear?). I'd really like to see all those Chris> "import *"'s go away. I have no problem with this. I think we should agree on a standard way of writing examples. I'm of two minds about how we should do this vis-a-vis numerix symbols. Approach 1: Help educate newbies about where symbols are coming from import pylab as p import matplotlib.numerix as nx x = nx.arange(100.0) y = nx.sin(2*nx.pi*x) p.plot(x,y) p.show() Approach 2: Given that the array packages are still being reorganized, use pylab as a namespace aggregator import pylab as p x = p.arange(100.0) y = p.sin(2*nx.pi*x) p.plot(x,y) p.show() 1 looks better to me for the standard symbols (arange, pi, etc...) but when you start to include linear algebra, FFT, MLab, etc, I am not sure. Currently mpl numerix uses the numarray hierarchy: is there any advanced word on whether this will be used in Numeric3? import matplotlib.numeric.fft as nxfft import matplotlib.numeric.mlab as nxmlab ??? Basically, the question is, do we want to encourage using pylab as a namespace aggregator to hide the complexity of where all these symbols are coming from in packages whose organization is still evolving? Also, I still want to support the 'from somewhere import something' style of import since I think it makes the scripts more friendly to read for many from a procedural programming background.. from pylab import hist, show Chris> One way to get there is to add much of the functionality of Chris> pylab to the OO interface. I really wish I had the time to Chris> write an OO-pylab, I think it would be really great, even Chris> for interactive use. I think the OO interface is already pretty easy to use. Some ease of use areas I see are * Easier attribute setting (eg x.facecolor = 'r') but this is already accomplished somewhat since the set/get introspection facilities are now available in matplotlib.artist to the OO user * Have some way to enable auto-redraw on attribute change for interactive use. This could be accomplished fairly easily with an ipython hook * Make the backend figure canvas, figure import a little less wordy, Are there other areas you would like to see improved? There isn't a lot pylab does anymore, except manage the figure windows. And usually the API developer wants to do this in any case. JDH |
From: Chris B. <Chr...@no...> - 2005-05-24 16:26:26
|
A few comments: John Hunter wrote: > I have no problem with this. I think we should agree on a standard > way of writing examples. I'm of two minds about how we should do this > vis-a-vis numerix symbols. > > Approach 1: Help educate newbies about where symbols are coming from > > import pylab as p > import matplotlib.numerix as nx > > x = nx.arange(100.0) > y = nx.sin(2*nx.pi*x) > p.plot(x,y) > p.show() > > Approach 2: Given that the array packages are still being reorganized, > use pylab as a namespace aggregator > > import pylab as p > > x = p.arange(100.0) > y = p.sin(2*nx.pi*x) > p.plot(x,y) > p.show() Why use nx, rather than n? (or N, which is what I usually use). Actually, I usually use "import Numeric as N", I used Numeric long before I discovered matplotlib. I'd say that this decision should be driven somewhat by what you want matplotlib to be. I see it as a plotting package, and I see Numeric (or SciPyBase?) as a numerical array package. Given that, option (1) is the way to go. However, I can see the strong appeal of an all in one package, al la Matlab. If we go this route (which is kind of the route at the moment), we'll see lot of questions on this list that have nothing to do with matplotlib, and everything to do with Numerix. WE have that already, of course. I really would like to see a nice, unified, set of packages for doing scientific/numeric work with Python. I think SciPy is the natural place for this, NOT matplotlib. My ideal version would have matplotlib as a sub-package of SciPy. It looks like we get to the grand-unification of Numeric, as SciPy Base, that that's a good start. I don't recall why you didn't make matplotlib a subpackage of SciPy in the first place, but I can understand that it happened that way, and honestly, there have been a lot of "plotting for SciPy" starts, and none of them has gotten to the usefulness of matplotlib, so you certainly did something right! > 1 looks better to me for the standard symbols (arange, pi, etc...) but > when you start to include linear algebra, FFT, MLab, etc, I am not > sure. Currently mpl numerix uses the numarray hierarchy: is there any > advanced word on whether this will be used in Numeric3? I haven't noticed, but I'm guessing it'll be something like: import scipy.fft as fft > Basically, the question is, do we want to encourage using pylab as a > namespace aggregator to hide the complexity of where all these symbols > are coming from in packages whose organization is still evolving? I'd say no, but you're point about the still evolving is a good one. > Also, I still want to support the 'from somewhere import something' > style of import since I think it makes the scripts more friendly to > read for many from a procedural programming background.. > > from pylab import hist, show Sure. I do this a fair bit. I like it because it is explicit about where stuff is coming from. You're also right, if you are using a procedural style, typing "pylab." all the time gets pretty tiresome. > Chris> One way to get there is to add much of the functionality of > Chris> pylab to the OO interface. I really wish I had the time to > Chris> write an OO-pylab, I think it would be really great, even > Chris> for interactive use. > > I think the OO interface is already pretty easy to use. It may have gotten better. I haven't use it much recently, my main matplotlib using project has been handed off to another coder. I just remember that as much as I wanted to use the OO interface, It ended up being much easier to use pylab.whatever much of the time. Maybe the real problem isn't what's there, but what's in the examples. > * Easier attribute setting (eg x.facecolor = 'r') but this is > already accomplished somewhat since the set/get introspection > facilities are now available in matplotlib.artist to the OO user I just looked in the class docs, and I still can't see how to set something in an OO way, like the facecolor, for example: x.set('facecolor', 'r') maybe? I know I'd rather x.SetFaceColor('r') or something like that, but the above is OK too. > * Have some way to enable auto-redraw on attribute change for > interactive use. This could be accomplished fairly easily with an > ipython hook That would be nice. Having to call Figure.show() isn't too bad though. > * Make the backend figure canvas, figure import a little less wordy, Yes. What I'd like to be able to do is: import matplotlib as mpl F = mpl.Figure() A = F.plot(x,y) A.xlabel("some text") The only convenience you'd lose over the procedural interface is the "current figure/axis" concept, which I don't like much anyway. > Are there other areas you would like to see improved? There isn't a > lot pylab does anymore, except manage the figure windows. And > usually the API developer wants to do this in any case. Well, yes, for embedded use, but for quick scripts and interactive use, there should gbe an OO way to have your figure windows managed. It's probably time for me to put up or shut up...I hope I'll get a chance to put up soon. Maybe a good start would be to go through the tutorial and users guide, and try to re-write all the examples in an OO manner, and see what happens. -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: Ken M. <mc...@ii...> - 2005-05-24 18:30:10
|
On May 24, 2005, at 11:25 AM, Chris Barker wrote: > John Hunter wrote: >> Chris> One way to get there is to add much of the functionality of >> Chris> pylab to the OO interface. I really wish I had the time to >> Chris> write an OO-pylab, I think it would be really great, even >> Chris> for interactive use. >> I think the OO interface is already pretty easy to use. > > It may have gotten better. I haven't use it much recently, my main > matplotlib using project has been handed off to another coder. I just > remember that as much as I wanted to use the OO interface, It ended up > being much easier to use pylab.whatever much of the time. Maybe the > real problem isn't what's there, but what's in the examples. I've found the OO interface to be very pleasant to use. While learning matplotlib, I translated a bunch of the pylab examples to the OO API (look at the plot_XYZ() functions): http://agni.phys.iit.edu/~kmcivor/potpourri/wxmpl-demos.py >> * Easier attribute setting (eg x.facecolor = 'r') but this is >> already accomplished somewhat since the set/get introspection >> facilities are now available in matplotlib.artist to the OO user > > I just looked in the class docs, and I still can't see how to set > something in an OO way, like the facecolor, for example: > > x.set('facecolor', 'r') maybe? > > I know I'd rather x.SetFaceColor('r') or something like that, but the > above is OK too. I'm all for having more consistent accessors for the various object properties. Perhaps something like this would work well? (yeah, it's modeled on Tkinter's configure() method) # def set(cfgdict=None, **kwds) -> None x.set(facecolor='r', size=2) > Maybe a good start would be to go through the tutorial and users > guide, and try to re-write all the examples in an OO manner, and see > what happens. Feel free to use any of the examples in the file I've linked to above... they're all under the matplotlib license, as they're derived from the matplotlib example scripts. If anyone else is interested in working to develop a tutorial for matplotlib's OO API, please drop me a line... I have a vested interest in making matplotlib easier for busy developers to use. Ken |
From: John H. <jdh...@ac...> - 2005-05-24 18:43:46
|
>>>>> "Ken" == Ken McIvor <mc...@ii...> writes: Ken> I'm all for having more consistent accessors for the various Ken> object properties. Perhaps something like this would work Ken> well? (yeah, it's modeled on Tkinter's configure() method) Ken> # def set(cfgdict=None, **kwds) -> None Ken> x.set(facecolor='r', size=2) Well, the current approach is nothing if not consistent. The whole "set" functionality is based upon the objects having property setters. Eg, set(PROPERTYNAME=val) always calls set_PROPERTYNAME(val) The set function you propose is a good idea and trivial to write. Just add this function to matplotlib.artist.Artist def set(self, **kwargs): """ A tkstyle set command, pass kwargs to set properties """ ret = [] for k,v in kwargs.items(): k = k.lower() funcName = "set_%s"%k func = getattr(self,funcName) ret.extend( [func(v)] ) return ret I'll include this in the next release. Ken> If anyone else is interested in working to develop a tutorial Ken> for matplotlib's OO API, please drop me a line... I have a Ken> vested interest in making matplotlib easier for busy Ken> developers to use. I suggest extending Robert's tutorial linked here http://matplotlib.sourceforge.net/faq.html#OO Thanks! JDH |
From: Stephen W. <ste...@cs...> - 2005-05-31 23:55:42
|
Ken McIvor wrote: > http://agni.phys.iit.edu/~kmcivor/potpourri/wxmpl-demos.py An interesting looking script. But 'import wxmpl' fails on my system (MPL V0.80). Am I missing something? As an aside, it would be nice if a demo/tutorial script like this could be made backend-independent. I normally use TkAgg in preference to WX or WXAgg. |
From: Fernando P. <Fer...@co...> - 2005-06-01 00:26:43
|
Stephen Walton wrote: > Ken McIvor wrote: > > >> http://agni.phys.iit.edu/~kmcivor/potpourri/wxmpl-demos.py > > > An interesting looking script. But 'import wxmpl' fails on my system > (MPL V0.80). Am I missing something? http://agni.phys.iit.edu/~kmcivor/wxmpl/ (a bit of poking around recursively up his directories :) Best, f |
From: Ken M. <mc...@ii...> - 2005-06-01 01:01:03
Attachments:
oo-demos.py
|
On May 31, 2005, at 6:55 PM, Stephen Walton wrote: > Ken McIvor wrote: >> http://agni.phys.iit.edu/~kmcivor/potpourri/wxmpl-demos.py > > An interesting looking script. But 'import wxmpl' fails on my system > (MPL V0.80). Am I missing something? It's missing the `wxmpl' module, a library for rapidly embedding matplotlib in wxPython. I have not yet had the gumption to proselytize it. I hadn't intended for people to try to run the whole script, just to look at the plot_XZY() functions. > As an aside, it would be nice if a demo/tutorial script like this > could be made backend-independent. I normally use TkAgg in preference > to WX or WXAgg. All of the aforementioned plot_XZY() functions accept a Figure as their only argument and draw their plots onto the figure, so they're already backend independent. I have attached a script which uses `pylab.figure()' to handle the creation of the Figure and associated FigureCanvas. Run it from the command line, and it will present you with a list of demos. If your matplotlibrc isn't setup for interactive plotting via wxPython, Tkinter, or GTK you'll need to specify an appropriate backend to use: $ python oo-demos.py -dWXAgg Ken |
From: Stephen W. <ste...@cs...> - 2005-06-05 04:02:09
|
Ken McIvor wrote: > All of the aforementioned plot_XZY() functions accept a Figure as > their only argument and draw their plots onto the figure, so they're > already backend independent. I have attached a script which uses > `pylab.figure()' to handle the creation of the Figure and associated > FigureCanvas. Run it from the command line, and it will present you > with a list of demos. Very handy, and thanks for the work. I'm still getting used to OO style. |
From: Matt N. <new...@ca...> - 2005-05-24 18:38:22
|
I mostly agree with Chris's comments about matplotlib and Numeric/scipy, etc, and think that keeping the explicit namespace hierarchy is useful. If pylab.py added the line import matplotlib.numerix as NX (or something similar) then you could do this import pylab as p x = p.NX.arange(100.0) y = p.NX.sin(2*nx.pi*x) p.plot(x,y) p.show() If 'p.NX' seems too ugly, you could always do import pylab as p N = p.NX x = N.arange(100.0) y = N.sin(2*nx.pi*x) p.plot(x,y) p.show() That seems very easy to use and avoid namespace conflicts, and still keeps the hierarchy obvious enough to track down where any method originates from. My 2c, --Matt |
From: John H. <jdh...@ac...> - 2005-05-27 03:43:01
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> Why use nx, rather than n? (or N, which is what I usually Chris> use). Actually, I usually use "import Numeric as N", I used Chris> Numeric long before I discovered matplotlib. In my own scripts, I often use N to be the size of something. And I eschew capital letters for ease of typing. I prefer nx since it doesn't clash with many current scripts, is easy to type, and resonates with the current name numerix which for better or worse is the name mpl has used for Numeric/numarray integration. I'm not wed to "nx" though. Chris> I'd say that this decision should be driven somewhat by Chris> what you want matplotlib to be. I see it as a plotting Chris> package, and I see Numeric (or SciPyBase?) as a numerical Chris> array package. Given that, option (1) is the way to go. Chris> However, I can see the strong appeal of an all in one Chris> package, al la Matlab. If we go this route (which is kind Chris> of the route at the moment), we'll see lot of questions on Chris> this list that have nothing to do with matplotlib, and Chris> everything to do with Numerix. WE have that already, of Chris> course. Chris> I really would like to see a nice, unified, set of packages Chris> for doing scientific/numeric work with Python. I think Chris> SciPy is the natural place for this, NOT matplotlib. My Chris> ideal version would have matplotlib as a sub-package of Chris> SciPy. It looks like we get to the grand-unification of Chris> Numeric, as SciPy Base, that that's a good start. I don't Chris> recall why you didn't make matplotlib a subpackage of SciPy Chris> in the first place, but I can understand that it happened The historical reason was that scipy was considered hard to install. matplotlib was pure python until 0.5 or something like that, and depended only on Numeric and pygtk. Now mpl is fairly hard to install and much more elaborate, and scipy is getting much easier to install. If and when the time is right, and the powers that be want to integrate mpl with scipy, I am happy to do it. I've also raised objections in the past on the grounds that mpl release schedules are much faster than scipy release schedules, but we're starting to get slow and crotchety in our old age around here as well :-) Chris> that way, and honestly, there have been a lot of "plotting Chris> for SciPy" starts, and none of them has gotten to the Chris> usefulness of matplotlib, so you certainly did something Chris> right! Thanks. I think the key is a relentless focus on making plots "look good" and supporting all the reasonable features that people need. That's what drove me away from other alternatives, at least. I mean, as a self respecting open source/scientific python zealot, you're nowhere if your plots look like crap. Chris> I just looked in the class docs, and I still can't see how Chris> to set something in an OO way, like the facecolor, for Chris> example: Chris> x.set('facecolor', 'r') maybe? Chris> I know I'd rather x.SetFaceColor('r') or something like Chris> that, but the above is OK too. Use x.set_facecolor('r') All matplotlib properties work this way: OBJECT.set_PROPNAME(VAL). You should also be sure get your hands on a recent version of ipython; TAB completion is your friend. In mpl CVS, in response to this thread, I also added support for x.set(facecolor='r') which has the advantage of supporting multiple property names x.set(facecolor='red', linewidth=2, alpha=0.5) Chris> Well, yes, for embedded use, but for quick scripts and Chris> interactive use, there should gbe an OO way to have your Chris> figure windows managed. This sounds like what I call "pythonic matplotlib": using the pylab interface to manage the GUI windows and such, while retaining a pythonic coding style; eg, not relying on the current figure and axes state. See examples/pythonic_matplotlib.py Chris> It's probably time for me to put up or shut up...I hope Chris> I'll get a chance to put up soon. Chris> Maybe a good start would be to go through the tutorial and Chris> users guide, and try to re-write all the examples in an OO Chris> manner, and see what happens. Sounds like as good an idea as any. JDH |
From: Fernando P. <Fer...@co...> - 2005-05-26 18:00:17
|
John Hunter wrote: >>>>>>"Chris" == Chris Barker <Chr...@no...> writes: > > > Chris> Fernando Perez wrote: > > >> I'd also suggest removing from all example code 'from pylab > >> import *' statements. > > Chris> Here here! (hear hear?). I'd really like to see all those > Chris> "import *"'s go away. > > > I have no problem with this. I think we should agree on a standard > way of writing examples. I'm of two minds about how we should do this > vis-a-vis numerix symbols. > > Approach 1: Help educate newbies about where symbols are coming from > > import pylab as p Very minor suggestion: I prefer using capitals for these single-letter shortcuts for common modules, as in import pylab as P import scipy as S it's just that it makes them stand out more in the body of code, where a single little s or p easily gets lost. Just a little comment, f |
From: Derrick S. <Der...@no...> - 2005-05-18 17:05:50
|
Fernando Perez wrote: > John Hunter wrote: > >>>>>>> "Tim" == Tim Leslie <ti...@cs...> writes: >>>>>> >> >> >> I'm wondering if set is now a bad name for pylab to be using? >> >> Tim> +1 for changing it. >> >> Tim> I've also had this issue bite me when I was hacking together >> Tim> some code and wanted to use a python set. I'd be in favour of >> Tim> changing the pylab set to be called something else, although >> Tim> I don't have any good suggestions about what to change it >> Tim> to... >> >> Ouch, I hadn't thought of this. In the past, consensus has been that >> pylab should not override built-ins, eg the previous discussion on >> min/max which led us to rename these functions to amin/amax. Changing >> set, unfortunately, will break a lot of scripts. I think the best >> plan of action is to define a new function pset or setp (setp for "set >> property") which has the functionality of the old, and keep set around >> for a release or two issuing a warning with a line number so people >> can get their existing scripts cleaned up. > > > I'd also suggest removing from all example code 'from pylab import *' > statements. Frankly, after a while I've completely stopped using > 'from foo import *' in _any_ code I write, even small scripts. All I > use these days is code like: > > import Numeric as N > import scipy as S > import pylab as P > > The only place where I think that from-import-* is OK is at an > interactive prompt, where you are just doing experiments and not > writing reusable code. > > Since the examples tend to be the place that people learn from, I > think it would be a good idea to encourage safer practices by banning > the dangerous import-* idiom from there. > > Just my opinion. > > Best, > > f > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users As the new learner that Fernando alludes to, I'd like to second his opinion. As we speak, I'm looking through examples I've collected trying to piece together something useful for my work. The namespace conflicts are a huge frustration, especially with regard to numarray/Numeric overlap. As a newbie, this is almost a show stopper. I'll figure it out eventually I hope... |
From: Ted D. <ted...@jp...> - 2005-05-18 17:25:09
|
Here's another vote for ditching from import *. As we get more and more experience writing larger python programs, using import * just seems to cause more and more problems. Given the huge variety of modules out there, it's impossible to avoid name conflicts and it's almost impossible to track down conflicts when they occur. We've started instructing/pushing/cajoling our users to do exactly what Fernando has suggested: import pylab as P Ted At 10:04 AM 5/18/2005, Derrick Snowden wrote: >Fernando Perez wrote: > >>John Hunter wrote: >> >>>>>>>>"Tim" == Tim Leslie <ti...@cs...> writes: >>> >>> >> I'm wondering if set is now a bad name for pylab to be using? >>> >>> Tim> +1 for changing it. >>> >>> Tim> I've also had this issue bite me when I was hacking together >>> Tim> some code and wanted to use a python set. I'd be in favour of >>> Tim> changing the pylab set to be called something else, although >>> Tim> I don't have any good suggestions about what to change it >>> Tim> to... >>> >>>Ouch, I hadn't thought of this. In the past, consensus has been that >>>pylab should not override built-ins, eg the previous discussion on >>>min/max which led us to rename these functions to amin/amax. Changing >>>set, unfortunately, will break a lot of scripts. I think the best >>>plan of action is to define a new function pset or setp (setp for "set >>>property") which has the functionality of the old, and keep set around >>>for a release or two issuing a warning with a line number so people >>>can get their existing scripts cleaned up. >> >> >>I'd also suggest removing from all example code 'from pylab import *' >>statements. Frankly, after a while I've completely stopped using 'from >>foo import *' in _any_ code I write, even small scripts. All I use these >>days is code like: >> >>import Numeric as N >>import scipy as S >>import pylab as P >> >>The only place where I think that from-import-* is OK is at an >>interactive prompt, where you are just doing experiments and not writing >>reusable code. >> >>Since the examples tend to be the place that people learn from, I think >>it would be a good idea to encourage safer practices by banning the >>dangerous import-* idiom from there. >> >>Just my opinion. >> >>Best, >> >>f >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Oracle Space Sweepstakes >>Want to be the first software developer in space? >>Enter now for the Oracle Space Sweepstakes! >>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >>_______________________________________________ >>Matplotlib-users mailing list >>Mat...@li... >>https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >As the new learner that Fernando alludes to, I'd like to second his >opinion. As we speak, I'm looking through examples I've collected trying >to piece together something useful for my work. The namespace conflicts >are a huge frustration, especially with regard to numarray/Numeric >overlap. As a newbie, this is almost a show stopper. >I'll figure it out eventually I hope... > > > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users Ted Drain Jet Propulsion Laboratory ted...@jp... |
From: Ken M. <mc...@ii...> - 2005-05-24 19:02:16
|
On May 24, 2005, at 1:42 PM, John Hunter wrote: >>>>>> "Ken" == Ken McIvor <mc...@ii...> writes: > > Ken> I'm all for having more consistent accessors for the various > Ken> object properties. Perhaps something like this would work > Ken> well? (yeah, it's modeled on Tkinter's configure() method) > > Well, the current approach is nothing if not consistent. The whole > "set" functionality is based upon the objects having property > setters. Eg, set(PROPERTYNAME=val) always calls > set_PROPERTYNAME(val) In retrospect, "more consistent" was a poor choice of words. I believe I was thinking of some corner case where I had to do something like `obj.member.set_text("blah")' when I wrote it. Of course, I cannot find an example where you have to do this, so it's a good bet I was doing something daft. > Ken> If anyone else is interested in working to develop a tutorial > Ken> for matplotlib's OO API, please drop me a line... I have a > Ken> vested interest in making matplotlib easier for busy > Ken> developers to use. > > I suggest extending Robert's tutorial linked here > > http://matplotlib.sourceforge.net/faq.html#OO This tutorial looks like a great place to start. Thanks! Ken |
From: John H. <jdh...@ac...> - 2005-05-24 19:07:11
|
>>>>> "Ken" == Ken McIvor <mc...@ii...> writes: Ken> In retrospect, "more consistent" was a poor choice of words. Ken> I believe I was thinking of some corner case where I had to Ken> do something like `obj.member.set_text("blah")' when I wrote Ken> it. Of course, I cannot find an example where you have to do Ken> this, so it's a good bet I was doing something daft. No, this is pretty common. Eg, ax.xaxis.major.formatter and so on. But I think this kind of organization is OK. Especially in ipython, with tab completion :-) JDH |