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? .
Paul
On Sun, 2021-04-11 at 20:43 -0700, Guido van Rossum wrote:
> On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw <ba...@python.org>
> wrote:
> [snip]
> > 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. :-)
>
> [snip]
> > 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-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/2F5PVC5MOWMGFVOX6FUQOUC7EJEEXFN3/
> 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/PUO7U3ZUIJ24W32GM7PYT34RJ5MGWZOC/
Code of Conduct: http://python.org/psf/codeofconduct/
