I'm -1 on the specific of the proposal because "let" has a different semantic meaning in most languages (it's a general way of declaring a variable), and "in" already has a different semantic meaning in Python (it is an operator that implies a containment check). But you may be onto something. We want TypeVars to have well-defined scopes that are clearly delineated within the code. What if we modeled TypeVars as context managers? This would be similar to your proposal except that it would use "with / as" instead of "let / in". I think that "with / as" will feel more natural to most Python users. Here's what this would look like: ```python from types import TracebackType from typing import Any, Generic, Protocol, TypeVar from typing_extensions import Self class _TypeVar: def __init__(self, __name: str, *, bound: Any = None): self._name = __name def __enter__(self): return TypeVar(self._name) def __exit__( self, __exc_type: type[BaseException] | None, __exc_val: BaseException | None, __exc_tb: TracebackType | None, ) -> None: pass class SupportsSum(Protocol): def __add__(self, __other: object) -> Self: ... with _TypeVar("T", bound=SupportsSum) as T: class Adder(Generic[T]): def add(self, a: T, b: T) -> T: return a + b with _TypeVar("T") as T: with _TypeVar("U") as U: def two_tvars(x: T, y: U) -> T | U: return x if x else y Adder[int]().add(1, 2) two_tvars(1, "hi") ``` This is not only syntactically legal (and backward compatible!), but it's also semantically correct at runtime, and it runs without any issues. Both mypy and pyright generate errors, but they could easily be taught that this form is valid. So this would have all the advantages of your proposal plus it could be introduced with no grammar changes, no runtime changes, and full backward compatibility to all supported versions of Python.