You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Undefined name when using variable annotations #486
>>> Type: object
>>> deffoo(x: Type) -> None: ...
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'Type' is not defined
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.
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
@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?
Activity
asottile commentedon Oct 27, 2019
should that be:
srittau commentedon Oct 27, 2019
No,
Type: objectis correct syntax and actually preferred for type stubs, since the= ...part has no meaning.asottile commentedon Oct 27, 2019
Type: objectdoesn't introduce a name, which is why pyflakes (imo correctly) flags it as an undefined name laterasottile commentedon Oct 27, 2019
srittau commentedon Oct 27, 2019
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.asottile commentedon Oct 27, 2019
how should
__future__annotationsbe implemented? currentlypyflakeshas handling of it but it just defers the accesses until after the module has been parsedsrittau commentedon Apr 23, 2020
@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
ANNASSIGNhandler 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 toaddBinding) to be used in type annotations and potentially for #533 as well.handleNodeLoadneeds 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?asottile commentedon Apr 23, 2020
cool cool, there's an
_in_annotationthat should help with the second partFix undefined name in annotations
Fix undefined name in annotations
Fix undefined name in annotations
Fix undefined name in annotations
Fix undefined name in annotations (#535)
CristinaBotez-Ipsos commentedon Jun 10, 2026