On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw <barry@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!
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
[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!
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>