Re: [matplotlib-devel] units support in svn
On 3/21/07, John Hunter <[EMAIL PROTECTED]> wrote: > On 3/21/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > > > And yes, properties are actually OK even with 2.2, so there's no > > reason to avoid them (and they do provide a nicer, claner user API). > > Decorators are 2.4-only though. > > I'm not opposed to properties in principle -- I just didn't want to > start incorporating them by happenstance. We have the long running > unresolved issue of whether to use traits or properties, so I scrubbed > the properties as a foolish consitency, to stick to one design > approach until we have made a formal decision on how we want to > approach this, and then port mpl properties en masse. I wasn't really voting for properties or traits, that decision is ultimately your call. They both provide similar user-visible benefits (traits having more open-ended possibilities, of course). > But I think it would be a good idea to go ahead and derive Artist from > object to make sure this doesn't cause any troubles, and likewise for > the other top level classes, eg FigureCanvasBase and friends. Yes. I fail to understand why the python VM doesn't raise an exception of some kind when property() is called on an old-style class. It won't work anyway, so why the hell does it fail silently??? I'm sure Eric and I are not the only people to have wasted time on that particular trap. Cheers, f - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
On 3/21/07, Fernando Perez <[EMAIL PROTECTED]> wrote: > And yes, properties are actually OK even with 2.2, so there's no > reason to avoid them (and they do provide a nicer, claner user API). > Decorators are 2.4-only though. I'm not opposed to properties in principle -- I just didn't want to start incorporating them by happenstance. We have the long running unresolved issue of whether to use traits or properties, so I scrubbed the properties as a foolish consitency, to stick to one design approach until we have made a formal decision on how we want to approach this, and then port mpl properties en masse. But I think it would be a good idea to go ahead and derive Artist from object to make sure this doesn't cause any troubles, and likewise for the other top level classes, eg FigureCanvasBase and friends. JDH - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
Fernando Perez wrote: > On 3/21/07, Eric Firing <[EMAIL PROTECTED]> wrote: > >> Properties would be OK for 2.3; I was thinking we might want to use >> them. When a getter and setter already exist, all it takes is the one >> extra line of code, plus a suitable (unused) name for the property. I >> decided not to pursue traits (if at all) until we can use the Enthought >> package as-is. But I think that properties could be converted to traits >> very easily if we wanted to do that in the future, so starting with >> properties would not be wasted effort. This is getting a bit off-topic, >> though. > > Minor note: if you are going to use properties, make sure all classes > using them are new-style (inherit from object). With old-style > classes, properties fail in silent and mysterious ways that may lead > to much head-scratching. Not minor at all--I ran into exactly this problem a few months ago with my first foray into properties, and it did indeed take quite a bit of head-scratching before I realized the problem. And I am embarrassed to say that I had forgotten about it until your reminder above. Thanks. Eric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
On 3/21/07, Eric Firing <[EMAIL PROTECTED]> wrote: > Properties would be OK for 2.3; I was thinking we might want to use > them. When a getter and setter already exist, all it takes is the one > extra line of code, plus a suitable (unused) name for the property. I > decided not to pursue traits (if at all) until we can use the Enthought > package as-is. But I think that properties could be converted to traits > very easily if we wanted to do that in the future, so starting with > properties would not be wasted effort. This is getting a bit off-topic, > though. Minor note: if you are going to use properties, make sure all classes using them are new-style (inherit from object). With old-style classes, properties fail in silent and mysterious ways that may lead to much head-scratching. As far as I can see, it is not currently the case in lines.py (where Line2D inherits from Artist, which is an old-style class). agg.py, which makes extensive use of property(), has it properly wrapped in the following: import types try: _object = types.ObjectType _newclass = 1 except AttributeError: class _object : pass _newclass = 0 del types and then all calls to property() are of the form: if _newclass:x = property(_agg.point_type_x_get, _agg.point_type_x_set) Currently the only two files I see using property() are agg.py and lines.py; once artist.py is fixed to be new-style, things should be fine. And yes, properties are actually OK even with 2.2, so there's no reason to avoid them (and they do provide a nicer, claner user API). Decorators are 2.4-only though. Cheers, f - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
> > And I've gotten the units.py module down to a digestable 105 lines of > code! You must have done more work after writing your message--now wc reports only 87 lines! Thanks for all the explanations (I am gradually coming around...) and additional work. Minor points from a quick look at axes.py: a line in spy() got regressed, so I restored it (svn rev 3114); and **kwargs got added to the signatures of set_xlim and set_ylim, but they are not being used--all valid kwargs are explicit. I left this alone because maybe you are planning to pass kwargs through later. > > See if you find the new interface less onerous. There is still work > to do if we want to support this kind of thing -- one of the hard > parts is to modify the various plotting functions to try and get the > original data into the primitive objects, which the current approach > is building around. Looks promising. I see the problem, as in the example you pointed out with plotting multiple columns, but I don't have any suggestions yet. > > I've also gotten rid of all the decorators and properties. The code > is not python2.3 compatible. Properties would be OK for 2.3; I was thinking we might want to use them. When a getter and setter already exist, all it takes is the one extra line of code, plus a suitable (unused) name for the property. I decided not to pursue traits (if at all) until we can use the Enthought package as-is. But I think that properties could be converted to traits very easily if we wanted to do that in the future, so starting with properties would not be wasted effort. This is getting a bit off-topic, though. Aha! Now I see that lines.py still has a few properties but they are private. Eric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
On 3/20/07, Norbert Nemec <[EMAIL PROTECTED]> wrote: > I agree, though, that the units package itself should not be part of > matplotlib. But this is exactly > how I understand the idea by John Hunter: describe an interface to allow > the use of any third-party > unit package. That's exactly right -- we are not providing a units package and have no intention of providing one. What this implementation is providing is an interface that one can use with any units package, either a publicly released one or a home grown one. Whether the interface is robust enough to handle real world package remains to be seen with further use and testing -- this is a first cut at it. The basic_units package in examples/units was developed for prototyping and testing, and was not meant to be the foundation of a real units package. matplotlib.units.UnitConverter describes the basic interface a unit converter class must expose. > Of course, the whole thing only makes sense is there is a units package > that is fit for production use. Well, one can still use it to support home grown units, even if they aren't production ready. And as the example date_converter.py shows, the same framework works well for plotting custom types even if unit conversion is not needed. I think your suggestion of supporting default axis labels is also a good one -- the current implementation supports tick labeling an formatting and axis labeling is a natural target for unit handling also. JDH - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
FYI The unit system John is working on will be a huge improvement for the way we use MPL. Our users do a ton of plotting that involves unitized numbers vs time. We have our own unit class and time class and right now users have to convert the unitized numbers into floats in the correct units and convert the times to the correct MPL format in the correct reference frame. Being able to seamlessly pass these objects to MPL is going to make all of our plotting scripts much simpler to use, easier to understand, and much safer (by eliminating different unit/time frame problems). It's not a big deal to convert values when the plot is first created - where it makes the biggest difference is when you want to manipulate the plot after it's created (xlim for example). Being able to pass unitized numbers to the various manipulation methods is what makes everything much easier to use (especially when dates are being plotted). Ted At 02:15 PM 3/20/2007, Norbert Nemec wrote: >Actually, I like the idea of unit support quite a bit and could well >imagine that it makes sense >to support it explicitely in matplotlib. > >I am using physical units very frequently in my computations. Lacking a >robust units package, >I simply define the units as numerical constants without checks but at >least with comfortable >conversion. If there were a good units package, support in matplotlib >would mean that the axis >labels could automatically be completed with appropriate units without >need for explicit conversion. > >I agree, though, that the units package itself should not be part of >matplotlib. But this is exactly >how I understand the idea by John Hunter: describe an interface to allow >the use of any third-party >unit package. > >Of course, the whole thing only makes sense is there is a units package >that is fit for production use. > > > >Darren Dale wrote: > > > > My first impression is similar to Eric's. I don't know if there > is a robust > > units package for python, but I imagine it should be a part of > scipy. I think > > it would be better to get an array and if you wanted to plot it > in different > > units, you call a method on the array at plot time. Maybe I dont > understand > > all the intended uses. > > > > Darren > > > > > > >- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >___ >Matplotlib-devel mailing list >Matplotlib-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
Actually, I like the idea of unit support quite a bit and could well imagine that it makes sense to support it explicitely in matplotlib. I am using physical units very frequently in my computations. Lacking a robust units package, I simply define the units as numerical constants without checks but at least with comfortable conversion. If there were a good units package, support in matplotlib would mean that the axis labels could automatically be completed with appropriate units without need for explicit conversion. I agree, though, that the units package itself should not be part of matplotlib. But this is exactly how I understand the idea by John Hunter: describe an interface to allow the use of any third-party unit package. Of course, the whole thing only makes sense is there is a units package that is fit for production use. Darren Dale wrote: > > My first impression is similar to Eric's. I don't know if there is a robust > units package for python, but I imagine it should be a part of scipy. I think > it would be better to get an array and if you wanted to plot it in different > units, you call a method on the array at plot time. Maybe I dont understand > all the intended uses. > > Darren > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
On Tuesday 20 March 2007 3:50:07 am Eric Firing wrote: > John Hunter wrote: > > If you are using mpl svn, please read this as it describes > > some fairly major changes. > > > > Mike Lusignan has been working on adding units support, and as a > > consequence, partial support for working with arbitrary types in mpl. > > The support is not complete yet, but it is basically working and > > compatible with the rest of mpl, so I thought now would be a good time > > to integrate it into the svn HEAD (he's been working in a branch) > > and get some more eyeballs on it. > > John, > > You accidentally whacked out the new Axes.matshow, so I put it back. > > I also noticed a few decorators--gasp!--in axes.py. I presume you will > want them replaced by old-style syntax to preserve 2.3 compatibility, > but I will leave that to you. (After about the 10th or so time of > reading a bit about decorators, I think I understand them enough for > simple use cases; apart from that ugly and utterly unpythonic @ symbol, > maybe they are not as bad as I thought.) > > The curmudgeon in me has to wonder whether the snazzy unit support is > really a good thing; this is partly a question of where the boundary of > a plotting library should be. The simpler view (classic mpl) is that > the role of mpl is to do a good job plotting numbers and labeling > things, and the role of the user or application programmer is to supply > the numbers and labels. I am not sure that enough is gained by enabling > unit conversion and automatic axis labeling inside a plot command to > compensate for the added complexity. My hesitation probably reflects > the facts (1) that I don't see any *compelling* use cases in the sort > of work I do, (2) I am not familiar with whatever use cases motivated > this, (3) I haven't thought about it much yet, and (4) I may be a bit > unimaginative. My first impression is similar to Eric's. I don't know if there is a robust units package for python, but I imagine it should be a part of scipy. I think it would be better to get an array and if you wanted to plot it in different units, you call a method on the array at plot time. Maybe I dont understand all the intended uses. Darren -- Darren S. Dale, Ph.D. [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] units support in svn
John Hunter wrote: > If you are using mpl svn, please read this as it describes > some fairly major changes. > > Mike Lusignan has been working on adding units support, and as a > consequence, partial support for working with arbitrary types in mpl. > The support is not complete yet, but it is basically working and > compatible with the rest of mpl, so I thought now would be a good time > to integrate it into the svn HEAD (he's been working in a branch) > and get some more eyeballs on it. John, You accidentally whacked out the new Axes.matshow, so I put it back. I also noticed a few decorators--gasp!--in axes.py. I presume you will want them replaced by old-style syntax to preserve 2.3 compatibility, but I will leave that to you. (After about the 10th or so time of reading a bit about decorators, I think I understand them enough for simple use cases; apart from that ugly and utterly unpythonic @ symbol, maybe they are not as bad as I thought.) The curmudgeon in me has to wonder whether the snazzy unit support is really a good thing; this is partly a question of where the boundary of a plotting library should be. The simpler view (classic mpl) is that the role of mpl is to do a good job plotting numbers and labeling things, and the role of the user or application programmer is to supply the numbers and labels. I am not sure that enough is gained by enabling unit conversion and automatic axis labeling inside a plot command to compensate for the added complexity. My hesitation probably reflects the facts (1) that I don't see any *compelling* use cases in the sort of work I do, (2) I am not familiar with whatever use cases motivated this, (3) I haven't thought about it much yet, and (4) I may be a bit unimaginative. I will try to take a closer look, both at the changes and at the questions you raise in your message, tomorrow. Eric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
