On Mon, Jul 21, 2008 at 04:42:39PM -0700, Ted Drain wrote:
> The public layer would just do conversions and then pass through to the
> private layer. Any code in the public layer would have to concern itself
> with possible different types (numpy vs lists, units vs floats, color names
> vs rgb).
Sent: Monday, July 21, 2008 3:40 PM
> To: Michael Droettboom
> Cc: matplotlib development list; Eric Firing
> Subject: Re: [matplotlib-devel] units support
>
> On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
> > I'll second be
On Mon, Jul 21, 2008 at 5:25 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I'll second being confused at times. In the transformation conversion, it
> was something I didn't know too much about up front, so it's quite possible
> that I broke some things in that regard. (I know of some alrea
I'll second being confused at times. In the transformation conversion,
it was something I didn't know too much about up front, so it's quite
possible that I broke some things in that regard. (I know of some
already, but those were fixed shortly after things were merged into the
trunk around 0
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
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
sta
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
>>
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
>
> 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/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
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
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
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
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 bas
14 matches
Mail list logo
