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?
(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: ...
```
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?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/U3TBVMXBXDCLTW7AAF5RAYKUMHKOYPBW/
Code of Conduct: http://python.org/psf/codeofconduct/
