(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:jdh2...@gmail.com] > 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 <jreva...@earthlink.net> > 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 > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
