8000 DEP: Futurewarn on requiring __len__ on array-likes by seberg · Pull Request #17973 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

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

Merged
merged 1 commit into from
Dec 18, 2020

Conversation

seberg
Copy link
Member
@seberg seberg commented Dec 9, 2020

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:

  • Basic tests for the deprecated paths (actually testing the deprecation)
  • A (hopefully quick) check whether this is actually what happened for __array__ and __array_struct__, since in principle they might behave differently.

@seberg seberg force-pushed the require-sequence-array-coercion branch from 4e3ba9b to abc528e Compare December 9, 2020 22:27
@seberg seberg force-pushed the require-sequence-array-coercion branch 2 times, most recently from b2dc230 to bc094a2 Compare December 10, 2020 19:46
return -1;
}
Py_DECREF(arr);
return max_dims;
Copy link
Member Author

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.)

@seberg seberg added the 09 - Backport-Candidate PRs tagged should be backported label Dec 10, 2020
@seberg seberg added this to the 1.20.0 release milestone Dec 10, 2020
@seberg seberg force-pushed the require-sequence-array-coercion branch from bc094a2 to 62a712e Compare December 10, 2020 20:20
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).
@seberg seberg force-pushed the require-sequence-array-coercion branch from 62a712e to 8caabdf Compare December 10, 2020 22:13
@charris charris merged commit bac54ec into numpy:master Dec 18, 2020
@charris
Copy link
Member
charris commented Dec 18, 2020

Thanks Sebastian.

@charris charris removed the 09 - Backport-Candidate PRs tagged should be backported label Dec 18, 2020
@charris charris removed this from the 1.20.0 release milestone Dec 18, 2020
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0