One disadvantage is that let...in opens a new scope without adding an
indentation level, which is weird for python. Decorators are nice because
their scoping is already well understood.
martin
On Tue, Apr 5, 2022 at 8:55 PM Jelle Zijlstra
I have another alternative idea. It will look like this:
let T = TypeVar("T") in class list(Generic[T]): def append(self, obj: T, /) -> None: ...
let T = TypeVar("T") in let U = TypeVar("U") in def two_tvars(x: T, y: U) -> T | U: ...
SimpleGenerator: TypeAlias = let T = TypeVar("T") in Generator[T, None, None]
def make_identity_func() -> let T = TypeVar("T") in Callable[[T], T]: ...
`let` would be a new soft keyword. The syntax would be available in all expressions and in class and def statements.
At runtime, the first example would be equivalent to something like:
T = TypeVar("T") class list(Generic[T]): def append(self, obj: T, /) -> None: ... # allow runtime introspection of parameters list.__set_parameters__({"T": T}) del T
Advantages: * Less new syntax, so it is easier to get into the language and easier to extend with new flavors of type variables that we may introduce in the future. * The new syntax is potentially useful outside of typing. * Allows a way to explicitly scope type variables to part of a type or to a type alias.
Disadvantages: * Less elegant syntax for generic classes (the flipside of it being more general). * Does not remove the redundancy in T = TypeVar("T")
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mdemello@google.com