-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Conditional import of typing_extensions gives "Incompatible import" #9856
Comments
You can use sys.version_info checks to do this without a type ignore. Other, potentially less desirable solutions: If your installation of typing_extensions is unconditional, you can also unconditionally import from typing_extensions. In some cases with |
OK, if that's the recommended solution, then let's stick with that. It probably makes it easier to find old code in future as well (e.g. grepping for "3, 8" when dropping support for 3.7). Maybe adding this to the common problems in the docs or something would useful though. |
Fixes #8629, fixes #8523. This creates a new page to document issues arising from discrepancies between the runtime and annotations. I felt this was better, rather than force-fitting things into existing pages and "common issues", for instance, it prevents us from having to explain PEP 563 in several different places. I do still list the runtime errors you'd get in the "common issues" page to preserve SEO :-) "String literal types", "Class name forward references", and "Import cycles" are basically the same as where they were copied over from. This also factors out the documentation of PEP 604 that I promised when merging that PR (it seemed pretty verbose, particularly for the "kinds of types" page). It's also a good place to document PEP 613, when we get around to supporting that. Resolves #9856. Co-authored-by: hauntsaninja <>
Fixes #8629, fixes #8523. This creates a new page to document issues arising from discrepancies between the runtime and annotations. I felt this was better, rather than force-fitting things into existing pages and "common issues", for instance, it prevents us from having to explain PEP 563 in several different places. I do still list the runtime errors you'd get in the "common issues" page to preserve SEO :-) "String literal types", "Class name forward references", and "Import cycles" are basically the same as where they were copied over from. This also factors out the documentation of PEP 604 that I promised when merging that PR (it seemed pretty verbose, particularly for the "kinds of types" page). It's also a good place to document PEP 613, when we get around to supporting that. Resolves #9856. Co-authored-by: hauntsaninja <>
When doing:
We get:
Unless I'm mistaken, this is a common pattern for supporting older Python versions. Therefore, it would ideally not trigger these errors, even if it has to be special cased.
The text was updated successfully, but these errors were encountered: