8000 BUG: np.<ufunc>(np.ndarray) should raise TypeError · Issue #8877 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

BUG: np.<ufunc>(np.ndarray) should raise TypeError #8877

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.

Sign up for GitHub

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

Jump to bottom
Closed
mhvk opened this issue Mar 30, 2017 · 4 comments · Fixed by #16941
Closed

BUG: np.<ufunc>(np.ndarray) should raise TypeError #8877

mhvk opened this issue Mar 30, 2017 · 4 comments · Fixed by #16941
Labels
00 - Bug component: numpy._core

Comments

@mhvk
Copy link
Contributor
mhvk commented Mar 30, 2017

As noted by @charris in charris#5 (comment)

In [3]: np.add(int, int)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-979cc31d12eb> in <module>()
----> 1 np.add(int, int)

TypeError: unsupported operand type(s) for +: 'type' and 'type'

In [4]: np.add(ndarray, ndarray)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-6dcac5b0c00d> in <module>()
----> 1 np.add(ndarray, ndarray)

ValueError: invalid __array_struct__

Should really both be TypeError.

Similarly, the following is arguably less than useful:

In [2]: np.sin(int)
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-0b1d09c17e53> in <module>()
----> 1 np.sin(int)

AttributeError: type object 'int' has no attribute 'sin'
@mhvk mhvk mentioned this issue Mar 30, 2017
Merged
@njsmith
Copy link
Member
njsmith commented Mar 31, 2017

The fix for the last case at least is the thing where we need to stop auto-coercing unrecognized objects into dtype=object arrays, as discussed multiple times.

8000
@eric-wieser
Copy link
Member
eric-wieser commented Jan 13, 2019 •
edited
Loading

Second half of this issue is fixed in #12700.

First half isn't really a ufunc problem at all, and comes from:

>>> np.array(np.ndarray)
Traceback (most recent call last):
  File "<pyshell#25>", line 1, in <module>
    np.array(np.ndarray)
ValueError: invalid __array_struct__

This happens because __array_struct__ is supposed to be <capsule object ...>, but for the ndarray type itself it's unavoidably <attribute '__array_struct__' of 'numpy.ndarray' objects>

This would be fixed by having np.array(x) use type(x).__array_struct__ instead of x.__array_struct__, which is how python does its magic method lookup normally.

Do we think we can get away with changing that?

@mhvk
Copy link
Contributor Author
mhvk commented Jan 13, 2019

Seems sensible to be consistent with how python does it.

@eric-wieser eric-wieser mentioned this issue Jan 26, 2019
Closed
@eric-wieser eric-wieser mentioned this issue Jul 24, 2020
Closed
seberg added a commit to seberg/numpy that referenced this issue Jul 24, 2020
@seberg
BUG: Allow array-like types to be coerced as object array elements
d45b16d 
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
@seberg seberg mentioned this issue Jul 24, 2020
Merged
@mhvk
Copy link
Contributor Author
mhvk commented Jul 28, 2020

Nice to see this resolved, thanks all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy._core
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

BUG: Allow array-like types to be coerced as object array elements seberg/numpy
4 participants
@eric-wieser @njsmith @mattip @mhvk
0