Re: Presenting PEP 695: Type Parameter Syntax

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.