-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Issues with conditional imports #1297
Comments
Also #1289. |
Also #1327. |
And #1334. |
I found that the following pattern can be used as a workaround in cases where you want to set a failed import to try:
from pip._vendor import colorama as _colorama
except Exception:
colorama = None
else:
colorama = _colorama This is to avoid the following error in the
|
As a (more) general solution to this problem, perhaps we could treat blocks like: try:
from foo import A
except ImportError:
A = None as and try:
from foo import A
except ImportError:
from bar import A # ( or even from bar import AA as A) as And so on. This is nice because you can do things like from typing import TypeVar
class A:
def __add__(self, a: A) -> str:
...
class AA:
def __add__(self, a: AA) -> str:
...
T = TypeVar('T', A, AA)
def add(a: T, b: T) -> T:
return a + b if A overrides This would lead to two issues:
For example, if you call the Hopefully this suggestion makes sense, let me know if there are questions or holes I am missing. |
An interesting idea! Treating conditionally imported types as type variables probably wouldn't work in some basic use cases, unfortunately. Here are some things that could cause trouble:
Some of these could be improved/fixed, but there may be other problematic things that we don't know about yet. |
Another example is #8319 (closing it as a duplicate). |
I have an issue related to mypy, conditional import and validation of the __all package attribute (defined as a Tuple containing variable number of items depending on the success of the conditional import). Consider following within package's init.py:
When this code is checked by mypy, it raises following error:
This issue keeps me from building Python package in the presence of 'mypy' check; I had to explicitly disable mypy check in order to build this package. I'd like to have mypy recognize possibility of variable-size Tuple in the presence of conditional import (and in general - same-name Tuple can be instantiated having different size depending on some conditions), or be able to ignore this error (unfortunately, mypy output does not report error number that can be ignored), or entirely exclude given file from mypy check (similarly to flake8's "exclude" in the setup.cfg). |
@vpogrebi This looks a little different from the other issues discussed here. Can you open a separate issue about conditionally defined |
New issue #8758 has been created. |
@JukkaL While introducing mypy to the CI for the Twisted codebase, I ran into this problem which is similar to the examples mentioned in this issue, similar to the one brought up by @ethanhs: twisted/twisted#1261 (comment) What is the way to deal with this:
Is there something that needs to be fixed in mypy?
to turn off mypy errors on that line. As much as possible, I want to avoid turning off mypy like that. The other option is to follow the example mentioned by @cjerdonek here: #1297 (comment) and do:
|
Interesting. Adam Johnson tried something similar, which fails in this gist. I've tried yours in this gist and it does work. Nice workaround. |
Closing, see here: #1153 (comment) |
Even though #649 was closed, there still remains several issues related to conditional imports. This issue is a top-level issue for these.
Related, more specific issues:
The text was updated successfully, but these errors were encountered: