Re: Presenting PEP 695: Type Parameter Syntax

El mar, 12 jul 2022 a las 6:15, Petr Viktorin (<[email protected]>)
escribió:

> On 12. 07. 22 6:30, Guido van Rossum wrote:
> > After several rounds of debate on typing-sig, I'd like to request
> > feedback on PEP 695: https://peps.python.org/pep-0695/
> > <https://peps.python.org/pep-0695/>
> >
> > I am sponsoring this PEP, which was written by Eric Traut. The PEP
> > attempts to solve the problem that defining generic classes, functions
> > and type aliases currently is lacking dedicated syntax, instead using
> > the cumbersome `T = TypeVar("T", ...)` notation to create global
> > variables that serve as type variables.
> >
> > As a personal historical note, I should mention that over 22 years ago I
> > already pondered type parameters. In an old document that I saved I
> > found the following code snippet:
> > ```
> > def f<T> (a: T) -> T: ...
> > ```
> > which is eerily close to the proposal in this PEP, except that the PEP
> > uses square brackets:
> > ```
> > def f[T](a: T) -> T: ...
> > ```
> > It's been a long and circuitous road!
> >
> > I am not quoting the entire PEP here, please follow the link:
> > https://peps.python.org/pep-0695/ <https://peps.python.org/pep-0695/>
> >
>
> A beautifully written PEP, thank you!
> An extra thank you for clearly specifying compile-/run-time vs. type
> checker behavior!
>
>
> In “Type Parameter Declarations” it would be nice to better specify why
> this example is an error:
> ```
> class ClassA[__T, _ClassA__S]:
>      __T = 0  # OK
>      __S = 0  # Syntax Error (because mangled name is _ClassA__S)
> ```
> It's specified later in the Compiler changes section (“An active type
> variable symbol cannot be used for other purposes”), but it would be
> nice to mention it up here too – perhaps replace the specific “Type
> parameters for a generic function cannot overlap the name of a function
> parameter.”
>
>
> I'm not a fan of a third overload of `type`, after the “get type of”
> function and “default metatype” class.
> Would `typevar` not work?
>

That piece of syntax is for type *aliases*, not type *variables*, which are
a different concept. Using "typevar" here would be quite confusing. We
could use something like "alias" or "typealias", but I think "type" is the
most intuitive term, and it matches other languages like TypeScript.


> (The addition of a soft keyword itself is a heavy change, though I'll
> let grammar experts weigh in on that.)
>
> I wonder if we should give some thought to other cases where a name is
> repeated – for example, a hypothetical:
>      namedtuple Point = ("x", "y")
> replacing:
>      Point = namedtuple("Point", ("x", "y"))
> Is the proposed `type` potentially setting a precedent? A good one?
>
>
> `TypeVar` taking `covariant`, `contravariant` and `autovariance` looks
> inconsistent to an outsider. Why is it not `autovariant`?
>
>
> The Rejected ideas mention “various syntactic options for specifying
> type parameters that preceded def and class statements” rejected because
> scoping is less clear and doesn't work well with decorators. I wonder if
> decorator-like syntax itself was considered, e.g. something like:
> ```
> @with type S
> @with type T
> @dec(Foo[S])
> class ClassA: ...
> ```
>
We did consider variations of that. Pure decorator syntax (like your "@dec"
line) wouldn't allow us to get the scoping right, since decorators can't
define new names. (Unless you use a walrus operator, but that wouldn't meet
the goal of providing cleaner syntax.)

We also considered some ideas similar to your "@with type". It can work,
but it feels more verbose than the current proposal, and it's not in line
with what most other languages do.


>
>
> And finally, I need to ask...
> The reference implementation doesn't include documentation. Is there any
> plan to document this feature outside this enhancement proposal?
>
> If not, what needs to happen to get this documented?
>

I'm sure we'll provide detailed documentation if and when the PEP is
accepted; full documentation seems a bit much to ask for in an early
prototype.


> _______________________________________________
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/U3TBVMXBXDCLTW7AAF5RAYKUMHKOYPBW/
> Code of Conduct: http://python.org/psf/codeofconduct/
>