[Numpy-discussion] NEP 30 - Duck Typing for NumPy Arrays - Implementation
chris.barker at noaa.gov
Mon Sep 16 17:55:20 EDT 2019
On Mon, Sep 16, 2019 at 1:46 PM Peter Andreas Entschev <peter at entschev.com>
> What would be the use case for a duck-array to implement __array__ and
> return a NumPy array?
some users need a genuine, actual numpy array (for passing to Cyton code,
if __array__ is not implemented, how can they get that from an array-like
Only the author of the array-like object knows how best to make a numpy
array out of it.
Unless I'm missing something, this seems
> redundant and one should just use array/asarray functions then.
but if the object does not impliment __array__, then user's can't use the
> would also prevent error-handling, what if the developer intentionally
> wants a NumPy-like array (e.g., the original array passed to the
> duckarray function) or an exception (instead of coercing to a NumPy
I'm really confused now -- if a end-user wants a duckarray, they should
call duckarray() -- if they want an actual numpy array, they should call
Why would anyone want an Exception? If you don't want an array, then don't
If you call duckarray(), and the object has not implemented __duckarray__,
then you will get an exception -- whoch you should.
If you call __array_, and __array__ has not been implimented, then you will
get an exception.
what is the potential problem here?
Which makes me think -- why should Duck arrays ever implement an __array__
method that raises an Exception? why not jsut not impliment it? (unless you
wantt o add some helpful error message -- which I did for the example in my
(PR to the numpy repo in progress)
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion