[Python-Dev] PEP 563: Postponed Evaluation of Annotations (original) (raw)

Lukasz Langa lukasz at langa.pl
Mon Nov 6 01:36:08 EST 2017

On 5 Nov, 2017, at 9:55 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

Python's name resolution rules are already ridiculously complicated, and PEP 563 is proposing to make them even worse, purely for the sake of an optional feature primarily of interest to large enterprise users.

Solving forward references in type annotations is one of the two explicit goals of the PEP. That alone changes how name resolution works. It sounds like you're -1 on that idea alone?

That's enough to leave nested classes as the main problematic case, since they can't see each other's attributes by default, and the proposed injected locals semantics in PEP 563 don't get this right either (they only account for MRO-based name resolution, not lexical nesting, even though the PEP claims the latter is expected to work)

You're right! I went too far here. I meant to be as compatible as possible with how regular attribute access works for nested classes. Originally I didn't want to support any locals at all for simplicity. I was convinced this is important (documented in "Rejected ideas") but overdid the example.

Since your example that illustrates the problem shows that those things fail for regular attribute lookup, too, that can be simply fixed in the PEP. I did that here: https://github.com/ambv/static-annotations/blob/master/pep-0563.rst#backwards-compatibility <https://github.com/ambv/static-annotations/blob/master/pep-0563.rst#backwards-compatibility>

Note that I am still including the "def method(self) -> D.field2:" example as valid as including a class' own name in the locals() chain map provided by get_type_hints() is going to be trivial. In fact, I think I'll add this to get_type_hints() independently of this PEP since users of string literal forward references probably don't expect it to fail for nested classes.

More information about the Python-Dev mailing list