El mar, 12 jul 2022 a las 6:15, Petr Viktorin (<encu...@gmail.com>) 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 -- 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/ >
_______________________________________________ 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/GOFZMCRZHSE7Y4FXAU27XS53TGGPDEXN/ Code of Conduct: http://python.org/psf/codeofconduct/
