I'm excited for this since I've always found the TypeVar approach a little cumbersome. I would only ask for the runtime aspect to also be considered. For example, cattrs can already handle creating MyClass[int] from json, so it would be great to keep that functionality.

Also, the approach with less importing is probably going to be more pleasant to use.

On Mon, Mar 14, 2022 at 4:39 PM Guido van Rossum <guido@python.org> wrote:
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)
_______________________________________________
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: tinchester@gmail.com