Re: [matplotlib-devel] Updated units.ConversionInterface

[John H. <jd...@gm...>]

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