[Matplotlib-devel] Units discussion...

[Nathan Goldbaum]

On Thu, Feb 8, 2018 at 1:08 PM, Drain, Theodore R (392P) <
theodore.r.drain at jpl.nasa.gov> wrote:

> Does numpy subclassing really matter?  If the docs say the unit converter
> must convert from the external type to the internal type, then as long as
> the converter does that, it doesn't matter what the external type is or
> what it inherits from right?  The point is that the converter class is the
> only class manipulating the external data objects - MPL shouldn't care what
> they are or what they inherit from.
>

To make my statement more concrete, here's a matplotlib pull request that
fixed a bug that only triggered for astropy and yt but not for pint:

https://github.com/matplotlib/matplotlib/pull/6622

In this case it was an issue because of difference in how NumPy's masked
array deals with ndarray subclasses versus array wrapper classes.


> I think one issue is that data types are malleable in the API right now.
> Lists, tuples, numpy, ints, floats, etc are all possible inputs in
> many/most cases.  IMO, the unit API should not be malleable at all.  The
> unit converter API should say that the return type of external->internal
> conversion is always a specific value type (e.g. list of float, numpy float
> 64 array).
>
> Jody: IMO, your example should plot the data in inches in the first plot
> call, then convert the second input to inches and plot that.  The plot
> calls supports the xunits keyword argument which tells the converter what
> floating point unit conversion to apply.  If that keyword is not specified,
> then it defaults to the type of the input.  The example that needs to be
> more clear is if I do this:
>
> ax.plot( x1, y1, xunits="km" )
> ax.plot( x2, y2, xunits="miles" )
>
> IMO, either the floats are km or miles, not both.  So either the first
> call sticks the converter to using km and the second xunits is ignored.  Or
> the second input overrides the first and requires that the first artists go
> back through a conversion to miles.  Either is a reasonable choice for
> behavior (but the first is much easier to implement).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20180208/07de0b18/attachment-0001.html>