[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)?

I am strongly in favor of diverging type annotation syntax from Python syntax. Currently, type annotations are a very useful tool, but often clunky to use. Enhancements have been made, but design space is limited when working within existing Python syntax. Type annotations have a different set of rules, needs, and constraints than general-purpose Python code. This is similar to other domain specific languages like regular expressions. Ideally, Python itself would not check the syntax of annotations, except as needed for determining the end of an annotation. PEP 563 is a step in that direction.

As far as I understand the arguments against PEP 563 and in favor of PEP 649 mostly boil down to "annotations are used outside of typing, these uses would need to use eval() in the future and eval() is slow". (At least from a user's perspective, there are more arguments from a Python maintainer's perspective that I can't comment on.) Are there benchmarks to verify that using eval() has a non-negligible effect for this use case? Overall, I don't find this to be a compelling argument when compared to the problem that PEP 649 would close all design space for type annotation syntax enhancements.

 - Sebastian