Typing Extension Mismatch #2162
Replies: 1 comment 2 replies
-
|
Type stubs generally represent the most recent version of a library. If you're using an older version of a library, there may be differences between the library and the corresponding type stubs. Upgrading to the latest version of the library will typically fix that problem. The best solution to this problem is for each library to ship its own type information, either inline or as bundled stubs. |
Beta Was this translation helpful? Give feedback.
-
|
How about typevartuple? That’s marked as fine by pyright due to the type shed-fallback but there is no possible package that has it yet. The latest typing extensions is missing it because the pep is still in progress. The current situation may be the best answer. Just a bit weird to have an import type check that can’t run on any library version yet. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, the bundled typeshed stubs contain a few features that don't yet exist in the actual typing_extensions library. If that bothers you, you can create your own copy of |
Beta Was this translation helpful? Give feedback.
-
Currently importing Paramspec in earlier versions of typing extensions without it is allowed by pyright. This works because pyright ends up using it's own type stubs for it (typeshed-fallback). But it fails at runtime since it doesn't actually exist in typing extensions for versions like 3.7.4.3. The issue also applies to other features that exist in eventual typing extensions even some that are not yet implemented in latest typing extensions (like typevartuple). All of these should be legal only in TYPE_CHECKING blocks and give an error message otherwise.
I considered marking this as a bug, but am bit unsure there's any way to mark type as only available at type checking time. Also I feel like the people that would trigger this error for using new type features to early would know the work around of TYPE_CHECKING.
Beta Was this translation helpful? Give feedback.
All reactions