8000 TYP: Assume that ``typing_extensions`` is always available in the stubs by jorenham · Pull Request #27132 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

TYP: Assume that typing_extensions is always available in the stubs #27132

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

jorenham
Copy link
Member
@jorenham jorenham commented Aug 7, 2024

Recently I found out that typing_extensions is always available in .pyi stubs (and when typing.TYPE_CHECKING) -- even if it's not available at runtime.
This is because the typeshed stubs for the standard library includes the typing_extensions.pyi stubs, so that type-checkers consider it a standard library (even though it might not exist at runtime).

This allows for most of the conditional-import code in *.pyi to be simplified, and is what I've done in this PR.
Apart from it being cleaner, more DRY, more readable, and easier to maintain, it makes the type stubs less incorrect, since if statements are a runtime thing, not a typing thing.
But even though type-checkers usually understood it in this particular case, it was bad practice to do so, and should be avoid if possible; hence this PR.


But the real great thing about this, is that we apparently are able to use all of those other cool new features from typing_extensions that aren't available in typing on Python 3.10.

The first example of this that comes to mind is PEP 696; which we could use so that complexfloating[N] is an alias for complexfloating[N, N].
It would also allow us to reduce the amount of overloads in case of parameters like spam: T = ... from 2 or 3 (in case it accepts both a positional or a keyword argument) to 1.

@rgommers
Copy link
Member

Looks like a nice simplification! Let me ping @Jacob-Stevens-Haas for another expert opinion, in case there's more to say about the "cool new features" part.

@jorenham jorenham force-pushed the typing/dtype-constructor-specialization branch from a1b1d8b to df43a58 Compare August 15, 2024 09:38
Copy link
Contributor
@Jacob-Stevens-Haas Jacob-Stevens-Haas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha I don't know if I'd call myself a typing expert, but I know enough to appreciate learning about new typing features! Thanks for sharing!

This is a great change. I have one suggestion, but I'm happy with whatever you choose.

Related question: if typeshed bundles typing extensions as part of the standard library, and all type checkers ship with typeshed, do dev-requirements.txt and environment.yml need to include typing_extensions?

@jorenham
Copy link
Member Author
jorenham commented Aug 15, 2024

if typeshed bundles typing extensions as part of the standard library, and all type checkers ship with typeshed, do dev-requirements.txt and environment.yml need to include typing_extensions?

Typeshed is used by type-checkers, and isn't even installable at runtime.
It doesn't "bundle" typing_extensions; it has provides typing_extensions typing stubs alongside the stubs for the standard library: https://github.com/python/typeshed/blob/main/stdlib/typing_extensions.pyi
So this tricks type-checkers (which only look at the stubs) into believing that typing_extensions is installed; even if it isn't. But because typing_extensions is a typing-only package by nature, that doesn't matter in practice; the stubs are enough.

So you'll still need to actually install typing_extensions if you want to use it outside of if TYPE_CHECKING: ... blocks in .py files.

@charris charris changed the title TYP: Assume that typing_extensions is always available in the stubs TYP: Assume that typing_extensions is always available in the stubs Aug 15, 2024
@jorenham jorenham force-pushed the typing/dtype-constructor-specialization branch from df43a58 to e55eb98 Compare August 16, 2024 11:47
Copy link
Member
@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewers & CI are happy, so in it goes. Thanks @jorenham

@rgommers rgommers merged commit ac97a65 into numpy:main Aug 26, 2024
66 checks passed
@rgommers rgommers added this to the 2.2.0 release milestone Aug 26, 2024
@jorenham jorenham deleted the typing/dtype-constructor-specialization branch August 26, 2024 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0