On Wed, Jan 28, 2009 at 3:16 PM, Drain, Theodore R
<[email protected]> 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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
