10000 BUG: Allow array-like types to be coerced as object array elements by seberg · Pull Request #16941 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

BUG: Allow array-like types to be coerced as object array elements #16941

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 2 commits into from
Jul 28, 2020

Conversation

seberg
Copy link
Member
@seberg seberg commented Jul 24, 2020

This was previously allowed for nested cases, i.e.:

np.array([np.int64])

but not for the scalar case:

np.array(np.int64)

The solution is to align these two cases by always interpreting
these as not being array-likes (instead of invalid array-likes)
if the passed in object is a type object and the special
attribute has a __get__ attribute (and is thus probable a
property or method).

The (arguably better) alterative to this is to move the special
attribute lookup to be on the type instead of the instance
(which is what python does). This will definitely require some
adjustments in our tests to use properties, but is probably
fine with respect to most actual code.
(The tests more commonly use this to quickly set up an
array-like, while it is a fairly strange pattern for typical code.)

Address parts of gh-16939
Closes gh-8877

This was previously allowed for nested cases, i.e.:

   np.array([np.int64])

but not for the scalar case:

   np.array(np.int64)

The solution is to align these two cases by always interpreting
these as not being array-likes (instead of invalid array-likes)
if the passed in object is a `type` object and the special
attribute has a `__get__` attribute (and is thus probable a
property or method).

The (arguably better) alterative to this is to move the special
attribute lookup to be on the type instead of the instance
(which is what python does). This will definitely require some
adjustments in our tests to use properties, but is probably
fine with respect to most actual code.
(The tests more commonly use this to quickly set up an
array-like, while it is a fairly strange pattern for typical code.)

Address parts of numpygh-16939
Closes numpygh-8877
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
@charris charris merged commit 62ca9df into numpy:master Jul 28, 2020
@charris
Copy link
Member
charris commented Jul 28, 2020

Thanks Sebastian.

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.

BUG: np.<ufunc>(np.ndarray) should raise TypeError
3 participants
0