MAINT,API: Introduce __numpy_dtype__ and fix dtype attribute recursion #30179
Conversation
This is a lot more complex then I expected. We, correctly, deprecated
`.dtype` attribute lookup recursion, however...
The code still had a `try/except` that still recursed and that try
except carried meaning at least in a weird path of:
```
class mydtype(np.void):
dtype = ...
```
Now does that make sense? Maybe not... we also fall back to object
in some paths which should have been broken when a dtype attribute
existed on a type but it is a property/descriptor.
So, this removes the recursion, but adds a check for `__get__` to
filter out those cases, this is something we successfully did for
other protocols `__array__`, `__array_interface__`, etc.
Signed-off-by: Sebastian Berg <[email protected]>
|
Would adding a |
|
Yeah, that is a nice thought, we should maybe add it to deprecate the use of the dtype on the instance. I guess that makesme lean to: worth an issue/followup, but maybe not needed here? |
| For array-like objects we encourage you to implement ``__numpy_dtype__`` | ||
| with a warning or error to _prevent_ using e.g. ``dtype=dataframe`` in | ||
| NumPy functions (it may be good to go via a Deprecation). |
There was a problem hiding this comment.
Do we really need other array libraries to take action? If they don't do anything, the status-quo for these types of array-likes is maintained (works or doesn't work depending on the case).
A warning / deprecation / error can be handled centrally in numpy. You could even make this behavior dependent on whether the passed object is array-like and/or whether they return a numpy dtype.
There was a problem hiding this comment.
Let me rephrase it to say that you could do this. NumPy would indeed deprecate it for you as soon as we actually deprecate .dtype.
I agree with that deprecation, but think we may want to wait a little bit, implementing it in the downstream library would be an early opt-in effectively.
This is a lot more complex then I expected. We, correctly, deprecated
.dtypeattribute lookup recursion, however...The code still had a
try/exceptthat still recursed and that try except carried meaning at least in a weird path of:Now does that make sense? Maybe not... we also fall back to object in some paths which should have been broken when a dtype attribute existed on a type but it is a property/descriptor.
So, this removes the recursion, but adds a check for
__get__to filter out those cases, this is something we successfully did for other protocols__array__,__array_interface__, etc.Closes gh-25306