Local vs global namespace to resolve forward annotations

[Viicos]

Consider the following example:

Code sample in pyright playground

from typing import TypeAlias, reveal_type

MyType: TypeAlias = int


class Class:
    MyType: TypeAlias = str

    forward: 'MyType'
    not_forward: MyType



reveal_type(Class().forward)  # int
reveal_type(Class().not_forward)  # str

I've tried looking into the typing spec and could only find an example related to method arguments, but I believe it should work the same:

The string literal should contain a valid Python expression (i.e., compile(lit, '', 'eval') should be a valid code object) and it should evaluate without errors once the module has been fully loaded. The local and global namespace in which it is evaluated should be the same namespaces in which default arguments to the same function would be evaluated.

(emphasis mine).

mypy seems to infer str for both types: https://mypy-play.net/?mypy=latest&python=3.12&gist=4e8df3bea67bf560e1fde83b1d9c14eb

Is this expected behavior? If not, should we also update/clarify the typing specification?

[erictraut]

Yeah, I don't think the typing spec provides much clarity on the intended behavior here. We should perhaps address this.

In cases like this, I look to the runtime behavior for clues about the correct behavior. In this case, pyright attempts to match the observed runtime behavior of typing.get_type_hints. For details, refer to PEP 563.

from typing import TypeAlias, get_type_hints

MyType: TypeAlias = int

class Class:
    MyType: TypeAlias = str

    forward: "MyType"
    not_forward: MyType

print(get_type_hints(Class))  # forward: int, not_forward: str

The behavior (non-intuitively) changes if you move the type alias definition to the bottom of the class.

from typing import TypeAlias, get_type_hints

MyType: TypeAlias = int

class Class:
    forward: "MyType"
    not_forward: MyType

    MyType: TypeAlias = str

print(get_type_hints(Class))  # forward: int, not_forward: int

For reference, here's the original pyright bug report that prompted me to change its behavior to match that of typing.get_type_hints.

[Viicos]

Thanks, this is interesting. This part of PEP 563 seems to be relevant:

An annotation is no longer evaluated at the time of definition and, more importantly, in the same scope where it was defined. Consequently, using local state in annotations is no longer possible in general.

This part of the typing.get_type_hints function seems to also be relevant:

if localns is None and globalns is None:
    # This is surprising, but required.  Before Python 3.10,
    # get_type_hints only evaluated the globalns of
    # a class.  To maintain backwards compatibility, we reverse
    # the globalns and localns order so that eval() looks into
    # *base_globals* first rather than *base_locals*.
    # This only affects ForwardRefs.
    base_globals, base_locals = base_locals, base_globals

[carljm]

Is it intentional that pyright also prefers global over local namespace for annotations in type stubs, even if not stringified?

[erictraut]

Pyright treats all annotations in stubs as though they are implicitly stringified. This comes directly from the typing spec, which says:

[In type stubs, t]ype checkers should evaluate all annotation expressions as if they are quoted

Pyright applies the same rule if you use from __future__ import annotations in a source file.

[Viicos]

I'm guessing this might change at some point, considering PEP 649 makes quoted annotations unnecessary, at least for type stubs?