All,
I have just submitted an updated units.ConversionInterface. For each of the static methods it now takes the invoking Axis instance
as a parameter. I have updated the appropriate calling functions. This allows the DateConverter to now guarantee that the default
axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime conversion error is now a lot more
difficult to invoke). Additionally I have modified the DateConverter class to make use of any specified units, such that the
timezone is used for the units value.
--James Evans
PS: I expect to be submitting a fully functioning test harness by the end of this week.
James Evans wrote:
All,
I have just submitted an updated units.ConversionInterface. For each of the static methods it now takes the invoking Axis instance
as a parameter. I have updated the appropriate calling functions. This allows the DateConverter to now guarantee that the default
axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime conversion error is now a lot more
difficult to invoke). Additionally I have modified the DateConverter class to make use of any specified units, such that the
timezone is used for the units value.
James,
I have not thought all this through, but a quick look at your changeset raises the question:
Why are you making such a complete change in the API? In every instance, you are changing the method signature so that the new arg, "axis", is the first. This seems particularly odd for the "convert" method--the new signature, convert(axis, value, unit), gives the arguments in what seems to be an unintuitive order. Why not have something like convert(value, unit, axis=None), so that convert can be called without specifying an axis, and so that the argument order is still natural: "convert the value with unit, taking advantage of the axis if specified"?
Is there some compelling logic to having the "axis" argument now at the head of the list?
Eric
···
--James Evans
PS: I expect to be submitting a fully functioning test harness by the end of this week.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Eric,
I was looking at it from the perspective of most of the other API calls throughout matplotlib have the Axes or Axis as the first
argument. Typically this is because it is what wants the work to be done or is being worked on. I was just following suit. I can
see where you are coming from. I have no real strong argument for or against, so if I should swap them around as you had suggested,
then I have no problem changing it.
--James
···
-----Original Message-----
From: Eric Firing [mailto:efiring@…229…]
Sent: Wednesday, January 28, 2009 10:48 AM
To: James Evans
Cc: 'matplotlib development list'
Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
James Evans wrote:
> All,
>
> I have just submitted an updated units.ConversionInterface. For each of the static methods it now
takes the invoking Axis instance
> as a parameter. I have updated the appropriate calling functions. This allows the DateConverter to
now guarantee that the default
> axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime
conversion error is now a lot more
> difficult to invoke). Additionally I have modified the DateConverter class to make use of any
specified units, such that the
> timezone is used for the units value.
>
James,
I have not thought all this through, but a quick look at your changeset
raises the question:
Why are you making such a complete change in the API? In every
instance, you are changing the method signature so that the new arg,
"axis", is the first. This seems particularly odd for the "convert"
method--the new signature, convert(axis, value, unit), gives the
arguments in what seems to be an unintuitive order. Why not have
something like convert(value, unit, axis=None), so that convert can be
called without specifying an axis, and so that the argument order is
still natural: "convert the value with unit, taking advantage of the
axis if specified"?
Is there some compelling logic to having the "axis" argument now at the
head of the list?
Eric
> --James Evans
>
> PS: I expect to be submitting a fully functioning test harness by the end of this week.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> matplotlib-devel List Signup and Options
I tend to agree with Eric -- then people writing converters who don't
care about the axis input can ignore it more easily.
JDH
···
On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jrevans1@...310...> wrote:
Eric,
I was looking at it from the perspective of most of the other API calls throughout matplotlib have the Axes or Axis as the first
argument. Typically this is because it is what wants the work to be done or is being worked on. I was just following suit. I can
see where you are coming from. I have no real strong argument for or against, so if I should swap them around as you had suggested,
then I have no problem changing it.
(nitpick mode on)
Saying they can ignore it more easily seems like a bit of a stretch to me. If you're writing a converter you MUST include the axis in the function signature since callers will be passing it in. Whether or not you use it in the converter implementation is obviously dependent on the converter. It's just as easy to not use the first argument in the list as it is the third.
(nitpick mode off)
Like James, I don't think the order is very important - but I do think it's important that the API not have a default value. Calling code in the Axes or wherever else MUST pass that argument because some converters will need it. The code at the upper layer should be independent of the type of converter that is being used. If you include a default value, someone will write new Axes code that calls the converter without passing the axis which will be wrong in some cases (just probably not the case they test with).
Ted
···
-----Original Message-----
From: John Hunter [mailto:jdh2358@…149…]
Sent: Wednesday, January 28, 2009 11:46 AM
To: James Evans
Cc: matplotlib development list; Eric Firing
Subject: Re: [matplotlib-devel] Updated units.ConversionInterface
On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jrevans1@...310...> > wrote:
> Eric,
>
> I was looking at it from the perspective of most of the other API
calls throughout matplotlib have the Axes or Axis as the first
> argument. Typically this is because it is what wants the work to be
done or is being worked on. I was just following suit. I can
> see where you are coming from. I have no real strong argument for or
against, so if I should swap them around as you had suggested,
> then I have no problem changing it.
I tend to agree with Eric -- then people writing converters who don't
care about the axis input can ignore it more easily.
JDH
-----------------------------------------------------------------------
-------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I don't feel strongly about this at all, and any scenario proposed
here will work fine, but the interface
convert(value, unit, axis=None)
to me emphasizes that the axis is optional for people writing
converters. Eg we do this ticker.Formatter -- you get the position
passed in by the API, but most formatters don't care about it
def __call__(self, x, pos=None):
'Return the format for tick val x at position pos; pos=None
indicated unspecified'
raise NotImplementedError('Derived must overide')
Yes, the signature must accept the kwarg, and the API will pass it in,
but it basically signals to the person writing a custom formatter what
the important and optional parts are. Since you (the JPL) are
implementing the interface and are closest to it, I'll defer to your
judgement.
JDH
···
On Wed, Jan 28, 2009 at 3:16 PM, Drain, Theodore R <theodore.r.drain@...179...> wrote:
(nitpick mode on)
Saying they can ignore it more easily seems like a bit of a stretch to me. If you're writing a converter you MUST include the axis in the function signature since callers will be passing it in. Whether or not you use it in the converter implementation is obviously dependent on the converter. It's just as easy to not use the first argument in the list as it is the third.
(nitpick mode off)
Like James, I don't think the order is very important - but I do think it's important that the API not have a default value. Calling code in the Axes or wherever else MUST pass that argument because some converters will need it. The code at the upper layer should be independent of the type of converter that is being used. If you include a default value, someone will write new Axes code that calls the converter without passing the axis which will be wrong in some cases (just probably not the case they test with).