Maybe add semantical understanding of `assert not TYPE_CHECKING` (similar to `if not TYPE_CHECKING`)?
Background
I'm using a helper type definition from a stubs package in project. I'll call it MyHelperType here (if it matters, it's actually StrOrPromise from django-stubs). We have two deployment settings:
- In development settings, the stubs package is installed. Here, we'd like to always use its definition of
MyHelperType(for mypy, and typeguard runtime checks during tests and usage) - In a production setting, we don't want to require the stubs package, so we just want
MyHelperTypeto be anything that doesn't cause syntax errors, probably a type alias ofAny.
I expected this snippet of code work:
from typing import TYPE_CHECKING, Any
try:
# Helper Type import that may fail in production settings, abusing collections.abc.Sequence for this example
from collections.abc import Sequence as MyHelperType
except ImportError:
assert not TYPE_CHECKING
MyHelperType = Any
but mypy will give these errors:
main.py:8: error: Cannot assign to a type [misc]
main.py:8: error: Incompatible types in assignment (expression has type "object", variable has type "type[Sequence[Any]]") [assignment]
I would have assumed that assert not TYPE_CHECKING causes mypy to treat the except-block as if it was guarded by if not TYPE_CHECKING -- mypy does not give errors for this example:
from typing import TYPE_CHECKING, Any
if TYPE_CHECKING:
# Helper Type import that may fail in production settings, abusing collections.abc.Sequence for this example
from collections.abc import Sequence as MyHelperType
else:
MyHelperType = Any
However, this wouldn't give us run-time type checking provided by typeguard.
The current workaround for me is this more verbose/wet approach:
from typing import TYPE_CHECKING, Any
if TYPE_CHECKING:
from collections.abc import Sequence as MyHelperType
else:
try:
from collections.abc import Sequence as MyHelperType
except ImportError:
MyHelperType = Any
I may be missing background information or conclusions of past discussions, but to me it seems reasonable for mypy to understand assert not TYPE_CHECKING and treat the block / following statements as if they were guarded by if not TYPE_CHECKING. (I can see that this could be undesirable in other contexts, and that it may be disputable what should happen in case mypy cannot resolve the import.)