Hello!
Thanks for the decision, the points raised mostly make sense to me.
However, I find myself and a few others are a little confused by point 2. I
can read it as saying the following perhaps slightly contradictory things:
"It's good that PEP 677 is conservative and sticks to things Callable can
do"
"PEP 677 isn't necessary, since Callable can do everything currently
proposed"
"PEP 677 could be a slippery slope for further syntax expansions that can
do things Callable cannot"
Would the case for new syntax have been stronger if it was proposing
something Callable couldn't do? E.g., is the concern something like "The
cost of new syntax is best paid by expanding the realm of what is
expressible. While we see how PEP 677 could lead to such expansion in the
future, the merits of future expansion are currently uncertain and the
current proposal is too costly discussed on its own merits"?
Or is the concern forward compatibility in the eventuality of further
syntax expansions? PEP 677 did discuss "extended syntax", which the
proposed syntax would be forward compatible with.
https://www.python.org/dev/peps/pep-0677/#extended-syntax-supporting-named-a...
Or something else entirely! Would appreciate any clarity :-)
Thank you!
On Wed, 9 Feb 2022 at 19:45, Gregory P. Smith
Thank you PEP authors for producing a very well written and laid out PEP. That made it easy to understand the proposal, rationale, and alternatives considered. We agree that the existing typing.Callable syntax, while capable, is less than ideal for humans. That said, we deliberated last week and ultimately decided to reject PEP-677 Callable Type Syntax.
Why? Several considerations led us here:
1. We feel we need to be cautious when introducing new syntax. Our new parser presents understandably exciting opportunities but we don’t want its existence to mean we add new syntax easily. A feature for use only in a fraction of type annotations, not something every Python user uses, did not feel like a strong enough reason to justify the complexity needed to parse this new syntax and provide meaningful error messages. Not only code complexity, humans are also parsers that must look forwards and backwards.
2. While the current Callable[x, y] syntax is not loved, it does work. This PEP isn’t enabling authors to express anything they cannot already. The PEP explicitly chose be conservative and not allow more syntax to express features going beyond what Callable supports. We applaud that decision, starting simple is good. But we can imagine a future where the syntax would desire to be expanded upon.
3. In line with past SC guidance, we acknowledge challenges when syntax desires do not align between typing and Python itself. Each time we add syntax solely for typing it shifts us further in the direction of typing being its own mini-language so we aim to tread lightly in what gets added here. Adopting PEP 677 would lock us into its syntax forever, potentially preventing other future syntax directions.
4. We did not like the visual and cognitive consequence of multiple `->` tokens in a def. Especially when code is not formatted nicely. Though we admit the correlation between Python typing and formatter users is high.
## Recommendation for future syntax enhancements:
When proposing a syntax change, low complexity is better. While not always possible, it’s ideal if it could still be described using our old <=3.8 parser. It is important to have in mind that adding syntax that only our modern PEG parser can handle could lead to greater cognitive load and external tooling implementation costs.
This should not be read as a ban on PEG-only syntax, we just think it should be used for broadly applicable features or else be relatively unintrusive.
Thanks, The 3.11 Python Steering Council _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/NHCLHCU2... Code of Conduct: http://python.org/psf/codeofconduct/