I actually really like some variation on `@with type S`, or some other
variation that has a keyword, because that makes it much easier for
someone newly encountering one of these syntax constructs to search to
figure out what it does. If you didn't already know what the square
brackets did, how would you try and find out? "what do square brackets
mean in Python" would probably turn up a bunch of stuff about element
access, and maybe something about type generic parameters.
By contrast, `@with type S` is kinda self-explanatory, and even if it's
not, 'What does "with type" mean in Python' will almost certainly turn
up meaningful results.
An additional benefit is that I find some of these examples to be a bit
visually cluttered with all the syntax:
def func1[T](a: T) -> T: ... # OK
class ClassA[S, T](Protocol): ... # OK
Which would look less cluttered with a prefix clause:
@with type T def func1(a: T) -> T: ... # OK
@with type S @with type T class ClassA(Protocol): ... # OK
Of the objections to this concept in the PEP
<https://peps.python.org/pep-0695/#prefix-clause>, the most obvious one
to me was that the scoping rules were less clear, but it is not entirely
clear to me why the scope of the prefix clause couldn't be extended to
include class / function decorators that follow the prefix clause; the
choice of scoping seems like it was a defensible but mostly arbitrary
one. I think as long as the new prefix clause is something that was
syntactically forbidden prior to the introduction of PEP 695 (e.g.
`@with type` or `[typevar: S]` or whatever), it will be relatively clear
that this is not a normal decorator, and so "the scoping and time of
execution doesn't match decorators" doesn't seem like a major concern to
me relative to the benefits of using a more searchable syntax.
On 7/12/22 18:09, Jelle Zijlstra wrote:
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.
_______________________________________________
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/OB7TJYLEFYV6MGF5VB3FYVLH3QEIRKNT/
Code of Conduct: http://python.org/psf/codeofconduct/
