[Numpy-discussion] is __array_ufunc__ ready for prime-time?
ben.v.root at gmail.com
Tue Nov 7 09:53:28 EST 2017
Well, to get the ball rolling a bit, the key thing that matplotlib needs to
know is if `shape`, `reshape`, 'size', broadcasting, and logical indexing
is respected. So, I see three possible abc's here: one for attribute access
(things like `shape` and `size`) and another for shape manipulations
(broadcasting and reshape, and assignment to .shape). And then a third abc
for indexing support, although, I am not sure how that could get
On Mon, Nov 6, 2017 at 7:28 PM, Stephan Hoyer <shoyer at gmail.com> wrote:
> On Mon, Nov 6, 2017 at 2:29 PM Ryan May <rmay31 at gmail.com> wrote:
>> On Mon, Nov 6, 2017 at 3:18 PM, Chris Barker <chris.barker at noaa.gov>
>>> Klunky, and maybe we could come up with a standard way to do it and
>>> include that in numpy, but I'm not sure that ABCs are the way to do it.
>> ABCs are *absolutely* the way to go about it. It's the only way baked
>> into the Python language itself that allows you to register a class for
>> purposes of `isinstance` without needing to subclass--i.e. duck-typing.
>> What's needed, though, is not just a single ABC. Some thought and design
>> needs to go into segmenting the ndarray API to declare certain behaviors,
>> just like was done for collections:
>> You don't just have a single ABC declaring a collection, but rather "I am
>> a mapping" or "I am a mutable sequence". It's more of a pain for developers
>> to properly specify things, but this is not a bad thing to actually give
>> code some thought.
> I agree, it would be nice to nail down a hierarchy of duck-arrays, if
> possible. Although, there are quite a few options, so I don't know how
> doable this is. Any interest in opening up an issue on GitHub to discuss?
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion