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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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:ef...@ha...] > 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 > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
(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:jd...@gm...] > 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 <jre...@ea...> > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Wed, Jan 28, 2009 at 3:16 PM, Drain, Theodore R
<the...@jp...> 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).
>
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 1:19 PM, James Evans <jre...@ea...> 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
Okay. Done. --James > -----Original Message----- > From: John Hunter [mailto:jd...@gm...] > Sent: Wednesday, January 28, 2009 11:46 AM > To: James Evans > Cc: Eric Firing; matplotlib development list > Subject: Re: [matplotlib-devel] Updated units.ConversionInterface > > On Wed, Jan 28, 2009 at 1:19 PM, James Evans <jre...@ea...> 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