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 MyHelperType to be anything that doesn't cause syntax errors, probably a type alias of Any.

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.)

Riproduci i due esempi e l'attuale soluzione alternativa nei casi collegati di mypy-play, quindi traccia il modo in cui mypy gestisce le guardie TYPE_CHECKING e le istruzioni assert. Definisci il comportamento desiderato per assert not TYPE_CHECKING, inclusa la verifica delle assegnazioni, e aggiungi una copertura che mostri che il pattern proposto funziona senza modificare la semantica ordinaria di assert.