DEP: Futurewarn on requiring __len__ on array-likes #17973
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4e3ba9b to
abc528e
Compare
b2dc230 to
bc094a2
Compare
seberg
commented
Dec 10, 2020
| return -1; | ||
| } | ||
| Py_DECREF(arr); | ||
| return max_dims; |
There was a problem hiding this comment.
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. |
jackvreeken
added a commit
to pymoca/pymoca
that referenced
this pull request
Feb 15, 2021
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
jackvreeken
added a commit
to pymoca/pymoca
that referenced
this pull request
Feb 15, 2021
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
jackvreeken
added a commit
to pymoca/pymoca
that referenced
this pull request
Feb 15, 2021
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.