Skip to content
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

Closed
Dreamsorcerer opened this issue Dec 29, 2020 · 3 comments
Closed

Comments

@Dreamsorcerer
Copy link
Contributor

When doing:

try:
    from typing import Final
except ImportError:
    from typing_extensions import Final

We get:

error: Incompatible import of "Final" (imported name has type "typing_extensions._SpecialForm", local name has type "typing._SpecialForm")

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.

@Dreamsorcerer Dreamsorcerer added the bug mypy got something wrong label Dec 29, 2020
@hauntsaninja hauntsaninja added feature priority-2-low and removed bug mypy got something wrong labels Dec 29, 2020
@hauntsaninja
Copy link
Collaborator

hauntsaninja commented Dec 29, 2020

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 from __future__ annotations, you can use if TYPE_CHECKING to unconditionally import from typing_extensions without even installing typing_extensions.

@Dreamsorcerer
Copy link
Contributor Author

Dreamsorcerer commented Dec 29, 2020

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.

hauntsaninja pushed a commit to hauntsaninja/mypy that referenced this issue Dec 29, 2020
@hauntsaninja
Copy link
Collaborator

#9763 contains a lot more documentation for working around different type system features in different Pythons. I just added this commit to it b3d6644 :-)

JukkaL pushed a commit that referenced this issue Jan 6, 2021
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 <>
ilevkivskyi pushed a commit that referenced this issue Jan 19, 2021
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 <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants