-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
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
TYP: Assume that typing_extensions
is always available in the stubs
#27132
Conversation
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. |
a1b1d8b
to
df43a58
Compare
There was a problem hiding this 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
?
Typeshed is used by type-checkers, and isn't even installable at runtime. So you'll still need to actually install |
typing_extensions
is always available in the stubstyping_extensions
is always available in the stubs
df43a58
to
e55eb98
Compare
There was a problem hiding this 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
Recently I found out that
typing_extensions
is always available in.pyi
stubs (and whentyping.TYPE_CHECKING
) -- even if it's not available at runtime.This is because the
typeshed
stubs for the standard library includes thetyping_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 intyping
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 forcomplexfloating[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.