Repository navigation
TYP: Fixed & improved numpy.dtype.__new__ - #27139
Merged
charris merged 7 commits intoAug 30, 2024
Merged
Conversation
jorenham
force-pushed
the
typing/ufunc-constructor-specialization
branch
from
August 12, 2024 21:55
746e0b1 to
d816ff5
Compare
…iew]``. This adds an overload to ``__new__`` so that ``dtype(memoryview)`` returns ``dtype[void]`` instead of ``dtype[object_]``. It now matches the runtime behaviour.
…xible`` sctypes
jorenham
force-pushed
the
typing/ufunc-constructor-specialization
branch
from
August 15, 2024 10:45
d816ff5 to
9f03471
Compare
Member
|
Thanks @jorenham . |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The changes are mostly limited to the
numpy.dtype.__new__overloads:StringDType: Type-checkers will now allowdtype(np.dtypes.StringDType)(which previously would've been rejected), and correctly infer the return type of e.g.dtype('T')as-> StringDType.ctypes, or python builtin types, analogous to the scalar-type hierarchy. So callingdtype(arg)with somearg: str | bytesnow returns adtype[character](previously this wasdtype[object_]). And passingarg: Literal["int", "c16"]now results indtype[number[Any]](which wasdtype[Any]).dtype(memoryview), which was previously incorrectly annotated asdtype[object_], instead ofdtype[void]. This requires type-checkers to be PEP 688 compliant, otherwise these overloads are skipped, and the inferred type will be same same as it would've been before.See also Drop bytes/bytearray and bytes/memoryview promotions (PEP 688) python/mypy#15313 .
dtype(float)now returnsdtype[float64 | int_ | np.bool]. This is necessary because of the "special" way in whichfloatandcomplexshould be treated, according to the typing docs.dtype[object_]instead ofdtype[Any]. This was caused by the last overload with signature(type[object], ...) -> dtype[object_], which also matches e.g.int | str.This additionally adds several new literals to
numpy._typing._char_codesfor the abstract scalar types, and forStringDType.A quick example of why this is needed:
This
.pyiwas ran through basedpyright 1.15.2 (pyright 1.1.375), and uses the current main branch as the "prior".