TYP: Concrete float64 and complex128 scalar types with builtin bases - #27334
charris merged 2 commits into
Conversation
Sorry, something went wrong.
|
Thanks @jorenham . I'll go with your judgement here. |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
DOC: Add release notes for #27334
|
@jorenham Thanks for implementing these changes to resolve static type checking issues involving Python and numpy float types. At the time you implement them, did you also consider covering the case below (assigning a float to a np.float64)?
I installed latest numpy with your changes using: |
Sorry, something went wrong.
You're assigning a supertype to a subtype here; that's not valid. You also can't assign an int to a bool, but you can assign a bool to an int. |
Sorry, something went wrong.
At runtime, numpy.float64 subclasses builtins.float, and numpy.complex128 subclasses builtins.complex. But the typing stubs currently do not reflect this. The consequence is that e.g. spam: float = np.float64(22 / 7) will be marked as an error by static type-checkers.
This PR introduces concrete types for float64 and complex128 that, like at runtime, (also) inherit from the float and complex builtin types, respectively.
Note that that the amount of type-tests had to be adjusted to accommodate this change, doesn't reflect the impact of this change on existing codebases is this case. This is becaue the typing.assert that is used in these type-tests, requires the exact type to match, so assert_type considers floating[_64Bit] and float64 as totally different types, even though float64 <: floating[_64Bit]. So for existing typing annotations this won't require a change.
Fixes #23081
Fixes #21906
Fixes #23663