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 arbitr
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
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
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 righ
>
> 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 axe
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
