I'm in favour of the approach proposed in PEP 649.

Movie trailer: "In a world where annotations are arbitrary non-Python syntax..."

It seems to me we could always have annotations evaluate to Python expressions *and* support any arbitrary syntax (e.g. through Annotated[...] or similar mechanism). What would a relaxed inline syntax provide that a well-placed Annotated[type, ArbitraryNonPythonSyntax("...")] annotation wouldn't? . 


On Sun, 2021-04-11 at 20:43 -0700, Guido van Rossum wrote:
On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw <barry@python.org> wrote:
This is something the SC has been musing about, but as it’s not a fully formed idea, I’m a little hesitant to bring it up.  That said, it’s somewhat relevant: We wonder if it may be time to in a sense separate the typing syntax from Python’s regular syntax.  TypeGuards are a case where if typing had more flexibility to adopt syntax that wasn’t strictly legal “normal” Python, maybe something more intuitive could have been proposed.  I wonder if the typing-sig has discussed this possibility (in the future, of course)?

We haven't discussed this in typing-sig, but it so happens that a similar idea for JavaScript was mentioned to me recently, and at the time I spent about 5 seconds thinking about how this could be useful for Python, too.

Basically, where the original PEP 3107 proposed annotations to have the syntax of expressions and evaluate them as such, now that we've got PEP 563 which makes annotations available as strings and no longer attempts to evaluate them, we could relax this further and do something like just skipping tokens until a suitable delimiter is found (',' or ')' inside the parameter list, ':' for the return type). Of course, matching parentheses, brackets and braces should always be paired and the target delimiter should not terminate the scan inside such matched pairs.

It occurs to me that right now is actually very good time to think about this a little more, because we're at a crossroads, of sorts: we could adopt Larry Hastings' PEP 649, which reverses PEP 563 and makes annotations available at runtime as objects (e.g., `def f(x: int)` would have the `int` type object in the annotation instead of the string `"int"`). Or we could reject PEP 649, which leaves the door open for a more relaxed annotation syntax in the future (earliest in 3.11).

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. :-)

Agreed.  It’s interesting that PEP 593 proposes a different approach to enriching the typing system.  Typing itself is becoming a little ecosystem of its own, and given that many Python users are still not fully embracing typing, maybe continuing to tie the typing syntax to Python syntax is starting to strain.

It definitely is. Type checkers are still young compared to Python itself, and their development speed is much faster than that of Python. So whenever new syntax is required the strain becomes obvious. Thanks for making that observation!

Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/
Code of Conduct: http://python.org/psf/codeofconduct/