matplotlib-devel Mailing List for matplotlib

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

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

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

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

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.

Ryan May wrote:
> John Hunter wrote:
> 
>> On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
>> 
>>> Hi,
>>>
>>> Do the online docs automatically update themselves from changes in SVN? I
>>> thought there was a nightly cron. I made some changes a few days ago (just a few
>>> typos) and they haven't shown up online yet. The changes were to
>>> doc/users/shell.rst. I'm assuming I should see the corresponding changes on
>>> http://matplotlib.sourceforge.net/users/shell.html.
>>> 
>> I had them in a cron and voluntarily disabled it. I'm amenable to
>> re-enabling it. The problem is that as examples become available in
>> svn, they automatically get pushed out to the gallery, but these may
>> not run on the latest released version. I thought perhaps the site
>> should more closely track the latest released version, so the last few
>> times I've pushed the docs out, I did so from the branch. So if you
>> want to see doc changes get pushed out sooner, you should patch the
>> branch and merge to the trunk. I am in general a big fan of
>> encouraging people to use the svn snapshots as much as possible, and
>> updating the gallery and site docs nightly helps this because the new
>> features in the gallery entice them, but in the absence of nightly
>> builds and snapshots I don't think this is too helpful.
>> 
>
> Is there any way to merge changes done on the trunk onto the branch? Or should I
> just do it manually?
> 
I could set up merging from trunk to branch, but I'd like to discourage 
that in general. While we generally want all relevant changes merged 
from the branch to the trunk, that is not true in reverse (many things 
on the trunk are too risky to go to the branch). So, you end up doing a 
lot of manual cherry-picking when going in that direction, making 
svnmerge less helpful anyway.
Generally, if I forget to do something on the branch, I just do an SVN 
diff of what I did to the trunk, use that to patch my working copy of 
the branch, and then commit the branch.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Do the online docs automatically update themselves from changes in SVN? I
>> thought there was a nightly cron. I made some changes a few days ago (just a few
>> typos) and they haven't shown up online yet. The changes were to
>> doc/users/shell.rst. I'm assuming I should see the corresponding changes on
>> http://matplotlib.sourceforge.net/users/shell.html.
> 
> I had them in a cron and voluntarily disabled it. I'm amenable to
> re-enabling it. The problem is that as examples become available in
> svn, they automatically get pushed out to the gallery, but these may
> not run on the latest released version. I thought perhaps the site
> should more closely track the latest released version, so the last few
> times I've pushed the docs out, I did so from the branch. So if you
> want to see doc changes get pushed out sooner, you should patch the
> branch and merge to the trunk. I am in general a big fan of
> encouraging people to use the svn snapshots as much as possible, and
> updating the gallery and site docs nightly helps this because the new
> features in the gallery entice them, but in the absence of nightly
> builds and snapshots I don't think this is too helpful.
Is there any way to merge changes done on the trunk onto the branch? Or should I
just do it manually?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Jan 27, 2009 at 3:33 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Do the online docs automatically update themselves from changes in SVN? I
> thought there was a nightly cron. I made some changes a few days ago (just a few
> typos) and they haven't shown up online yet. The changes were to
> doc/users/shell.rst. I'm assuming I should see the corresponding changes on
> http://matplotlib.sourceforge.net/users/shell.html.
I had them in a cron and voluntarily disabled it. I'm amenable to
re-enabling it. The problem is that as examples become available in
svn, they automatically get pushed out to the gallery, but these may
not run on the latest released version. I thought perhaps the site
should more closely track the latest released version, so the last few
times I've pushed the docs out, I did so from the branch. So if you
want to see doc changes get pushed out sooner, you should patch the
branch and merge to the trunk. I am in general a big fan of
encouraging people to use the svn snapshots as much as possible, and
updating the gallery and site docs nightly helps this because the new
features in the gallery entice them, but in the absence of nightly
builds and snapshots I don't think this is too helpful.
JDH