-
-
Notifications
You must be signed in to change notification settings - Fork 11k
DEP: Futurewarn on requiring __len__ on array-likes #17973
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4e3ba9b
to
abc528e
Compare
b2dc230
to
bc094a2
Compare
return -1; | ||
} | ||
Py_DECREF(arr); | ||
return max_dims; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had this wrong first. Thought I can drop through to handle the scalar with the last fall-back path. This does not work, because it would break the current usage where we ignore everything from the __array__
protocol except the dtype. (The last fall-back forces object dtype.)
bc094a2
to
62a712e
Compare
This fixes issue numpygh-17965. The slightly annoying thing is that there is no simple way to opt-in to the new behaviour and the old behaviour is a bit quirky to begin with (honoring the dtype, but not the shape).
62a712e
to
8caabdf
Compare
Thanks Sebastian. |
Starting from, NumPy 1.20 behaves differently when instantiating arrays from array-like objects. NumPy used to be agnostic about the type of the object inside the list (MX in our case), but now it actually tries to interpret it as an array if it can. In this particular case, we deliberately _did not_ want this behavior. We use the work-around described in [0] to get the old behavior back. For more details, see: [0] https://numpy.org/devdocs/release/1.20.0-notes.html under "ArrayLike objects which do not define __len__ and __getitem__" or [1] numpy/numpy#17973
Starting from, NumPy 1.20 behaves differently when instantiating arrays from array-like objects. NumPy used to be agnostic about the type of the object inside the list (MX in our case), but now it actually tries to interpret it as an array if it can. In this particular case, we deliberately _did not_ want this behavior. We use something akin to the work-around described in [0] to get the old behavior back. For more details, see: [0] https://numpy.org/devdocs/release/1.20.0-notes.html under "ArrayLike objects which do not define __len__ and __getitem__" or [1] numpy/numpy#17973
Starting from, NumPy 1.20 behaves differently when instantiating arrays from array-like objects. NumPy used to be agnostic about the type of the object inside the list (MX in our case), but now it actually tries to interpret it as an array if it can. In this particular case, we deliberately _did not_ want this behavior. We use something akin to the work-around described in [0] to get the old behavior back. For more details, see: [0] https://numpy.org/devdocs/release/1.20.0-notes.html under "ArrayLike objects which do not define __len__ and __getitem__" or [1] numpy/numpy#17973
This fixes issue gh-17965. The slightly annoying thing is that
there is no simple way to opt-in to the new behaviour and the old
behaviour is a bit quirky to begin with (honoring the dtype, but
not the shape).
Marking as a draft for now, this still needs:
__array__
and__array_struct__
, since in principle they might behave differently.