I think it would be useful to compile a table of various ways one can use typevars to show the analogous syntax using each of the proposals. E.g.

# Classic
T = TypeVar("T")
class C(Generic[T]):
    def f(self, arg: T) -> T: ...

# Angle brackets
class C<T>:
    def f(self, arg: T) -> T: ...

# Square brackets
class C[T]:
    def f(self, arg: T) -> T: ...

# Decorator
@typevar("T")
class C:
    def f(self, arg: T) -> T: ...

Include examples using variance (could we use +T, -T for covariant, contravariant?), bounds and constraints. Show generic functions as well as classes. Go wild.

When using the decorator syntax, I have a question: how would the implementation of `typevar` insert the name "T" into the surrounding scope so that it can be used inside the class or function? sys._getframe()? (Urgh.)

On Mon, Mar 14, 2022 at 8:05 AM Sebastian Rittau <srittau@rittau.biz> wrote:
Am 14.03.22 um 15:51 schrieb Sergei Lebedev:

> class C[T, S]:
>     def foo[R=int](self) -> R: pass

Could you clarify what the "=int" part stands for?

A type var default (not currently supported by type vars).


> Some ideas how we could express upper bounds, constraints, and variance: [...]

Wdyt about <= for defining an upper bound and +/- for variance annotations? IIRC both are used at least in Scala and OCaml has +/- for specifying variance and </> for polymorphic variants.

This could work, but I'm not too fond of using too many punctuation characters. Python has always been the antithesis to "line-noise" Perl, and I think "key words" (not necessarily "keywords" from a parser perspective) are more readable and obvious.

* Could we make it work for ParamSpecs?

This is one more reason a decorator syntax could be better:

@paramspec("P")
def foo(*args: P.args, **kwargs: P.kwargs) -> None: ...

 - Sebastian
_______________________________________________
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: guido@python.org


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him (why is my pronoun here?)