BUG: Make sure that NumPy scalars are supported by can_cast #26372
BUG: Make sure that NumPy scalars are supported by can_cast #26372charris merged 2 commits intonumpy:mainfrom
Conversation
The main issue here was the order of the checks, since float64 is a subclass of float the error path was taken even though it should not have been. This also avoids converting to an array (which is very slow) when possible. I opted to use `scalar.dtype` since that may be a bit easier for potential future user dtype. That may not be quite ideal (I would like to not force `np.generic` as a base-class for user scalars), but is probably pretty close and more complicated fixes are probably not good for backport.
|
@charris do you prefer to split out the doc change, or apply this to the 2.0 branch first and forward port? |
Hmm, it is missing a link, which you cannot know until the PR is made. I'll take care of it in the backport, but it would probably be easier in the future to split it out and submit against the branch after the backport goes in. |
|
Ah right, I could just add a link to this PR (and try to find some link to something older to include here)? |
|
It may be nice if we could put this in and aim for a rc2 soon? E.g. the fft bug was hitting some downstream testers and it may be nice to resolve that. |
I was thinking next weekend so there would be a version out there with fixes. Could be earlier if needed. |
|
Thanks Sebastian. |
The main issue here was the order of the checks, since float64 is
a subclass of float the error path was taken even though it should
not have been.
This also avoids converting to an array (which is very slow) when
possible. I opted to use
scalar.dtypesince that may be a biteasier for potential future user dtype.
That may not be quite ideal (I would like to not force
np.genericas a base-class for user scalars), but is probably pretty close
and more complicated fixes are probably not good for backport.
Closes gh-26370
Also adds a
can_castchange to the relase notes as it was missing.