If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotations. I.e.

def test():

class C: ...

def func(arg: C): ...

return func

typing.get_type_hints(test()) # raises NameError: name 'C' is not defined

And that is a considerable concern (we've always let backwards compatibility count more strongly than convenience of new features). While it was known this would change, there was no real deprecation of the old way. Alas.

On Fri, Apr 16, 2021 at 1:51 AM Sebastian Rittau <srittau@rittau.biz> wrote:

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

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

_______________________________________________
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/RWLOLMWLPZ3O5VO7OQZSHTQGR4ICXDJV/
Code of Conduct: http://python.org/psf/codeofconduct/