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
implemented...
Cheers!
Ben Root
On Mon, Nov 6, 2017 at 7:28 PM, Stephan Hoyer
On Mon, Nov 6, 2017 at 2:29 PM Ryan May
wrote: On Mon, Nov 6, 2017 at 3:18 PM, Chris Barker
wrote: 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:
https://docs.python.org/3/library/collections.abc.html
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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion