16 Apr
2021
16 Apr
'21
4:21 p.m.
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