Hm, I was specifically thinking of things that introduce new keywords. For example, TypeScript adds unary operators 'infer' and 'keyof'. It would be rather difficult to have to define those as soft keywords throughout the language. (We couldn't just make them unary keywords, since 'infer (x)' should continue to call the function 'infer', for example. In an annotation context that might not be a problem, since function calls in general aren't valid types.)

IIRC Jukka also already brought up the possibility of using something like '(int) => str' instead of 'Callable[[int], str]' -- but it would be unpleasant if that syntax had a meaning like you propose outside annotations.

On Sat, Apr 17, 2021 at 7:12 PM Nick Coghlan <ncoghlan@gmail.com> wrote:

On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, <guido@python.org> wrote:

At the very least I recommend that the SC take this into account when they consider PEP 649. Accepting it has some nice benefits when it comes to the scoping rules for annotations -- but it would forever close the door for the "relaxed annotation syntax" idea you brought up. (Isn't it fun to be on the SC. :-)

I may have missed someone else mentioning this, but I don't think this concern is necessarily true, as even if PEP 649 were accepted, the only pre-PEP-563 constraints it would reintroduce would be that all future type annotation syntax:

* have a defined runtime effect;
* that runtime effect be consistent with normal expressions when reusing existing syntax; and
* be explicitly quoted when using type hinting syntax from later Python versions in code that needs to run on earlier versions

Any PEPs adding new type hinting specific syntax would be free to define the runtime effect of the new syntax as "produces a string containing the text of the part of the annotation using the new syntax, as if the new syntax were explicitly quoted", even if we decided not to go ahead with the idea of applying those "produces a string" semantics to *all* annotations.

Cheers,
Nick.