matplotlib-devel Mailing List for matplotlib

On 3/21/07, John Hunter <jd...@gm...> wrote:
> On 3/21/07, Fernando Perez <fpe...@gm...> 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

On 3/21/07, Fernando Perez <fpe...@gm...> 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

Fernando Perez wrote:
> On 3/21/07, Eric Firing <ef...@ha...> 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

On 3/21/07, Eric Firing <ef...@ha...> 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

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

On 3/20/07, Norbert Nemec <Nor...@gm...> 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