On 16 Apr 2021, at 16:59, Guido van Rossum wrote:

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

Can't this be solved by wrapping the annotation in a lambda, i.e.

>>> def test():
...   class C: ...
...   def func(arg: lambda: C): ...
...   return func
...
>>> test().__annotations__['arg']()
<class '__main__.test.<locals>.C'>

So typing.get_type_hints() would simply call an annotation if the annotation was callable and replace it with the result of the call.

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

--
--Guido van Rossum (python.org/~guido)

Servus,
Walter