TYP: Concrete float64 and complex128 scalar types with builtin bases#27334
Conversation
|
Thanks @jorenham . I'll go with your judgement here. |
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
I installed latest numpy with your changes using: |
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. |
3 participants
At runtime,
numpy.float64subclassesbuiltins.float, andnumpy.complex128subclassesbuiltins.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
float64andcomplex128that, like at runtime, (also) inherit from thefloatandcomplexbuiltin 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.assertthat is used in these type-tests, requires the exact type to match, soassert_typeconsidersfloating[_64Bit]andfloat64as totally different types, even thoughfloat64 <: floating[_64Bit]. So for existing typing annotations this won't require a change.Fixes #23081
Fixes #21906
Fixes #23663