Skip to content

Undefined name when using variable annotations #486

Closed

Description

@srittau

Please consider the following file:

Type: object
def foo(x: Type) -> None: ...

When checking it with '2.1.1 Python 3.8.0 on Linux' (or Python 3.7.3) I get the following error:

foo.py:2: undefined name 'Type'

This is problematic when checking python stub files.

Activity

  1. asottile commented on Oct 27, 2019

    @asottile
    Member

    should that be:

    Type: object = ...
  2. srittau commented on Oct 27, 2019

    @srittau
    MemberAuthor

    No, Type: object is correct syntax and actually preferred for type stubs, since the = ... part has no meaning.

  3. asottile commented on Oct 27, 2019

    @asottile
    Member

    Type: object doesn't introduce a name, which is why pyflakes (imo correctly) flags it as an undefined name later

  4. asottile commented on Oct 27, 2019

    @asottile
    Member
    >>> Type: object
    >>> def foo(x: Type) -> None: ...
    ...
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    NameError: name 'Type' is not defined
  5. srittau commented on Oct 27, 2019

    @srittau
    MemberAuthor

    Good point, although pyflakes also fails when using from __future__ import annotations, which works with Python ≥ 3.7. Stubs are treated like this import was present.

  6. asottile commented on Oct 27, 2019

    @asottile
    Member

    how should __future__ annotations be implemented? currently pyflakes has handling of it but it just defers the accesses until after the module has been parsed

  7. srittau commented on Apr 23, 2020

    @srittau
    MemberAuthor

    @asottile Sorry, I don't think I understand the question. I have no experience with how pyflakes is implemented if that is what you mean? I'll investigate.

    [some time later ...]

    I only looked at it superficially for now, so I might be on the wrong track here. I see two potential areas that need to be changed: The ANNASSIGN handler currently ignores nodes without a value. That makes sense, since they don't generate a name. Nevertheless it should record the defined names somewhere (in parallel to addBinding) to be used in type annotations and potentially for #533 as well.

    handleNodeLoad needs to be modified to use the new names record, but only in the context of type annotations. This is the hard part, since at that point it is not clear that we are parsing an annotation. Maybe a parse-level flag needs to be set while parsing annotations?

  8. asottile commented on Apr 23, 2020

    @asottile
    Member

    cool cool, there's an _in_annotation that should help with the second part

  9. added 4 commits that reference this issue on Apr 26, 2020
    0dcd9ee
    afbc8b5
    8801bc3
    13771a9
  10. added a commit that references this issue on Sep 28, 2020
    5fc37cb
  11. CristinaBotez-Ipsos commented on Jun 10, 2026

    @CristinaBotez-Ipsos
  12. locked as off topic and limited conversation to collaborators on Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions