Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No reveal_type diagnostic for variables with bare type qualifier annotations #9720

Open
sharkdp opened this issue Jan 17, 2025 · 1 comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working

Comments

@sharkdp
Copy link

sharkdp commented Jan 17, 2025

Describe the bug

Pyright seems to omit reveal_type diagnostics for class variables annotated with a bare ClassVar or a bare Final (the latter of which makes little sense without an assignment).

This is certainly not a big problem, just a little surprising, as Pyright even shows diagnostics for symbols that are not defined at all (reveal_type(not_defined_anywhere)). It's not entirely clear to me if a bare ClassVar should even be allowed (it's not mentioned anywhere in the documentation/spec), and a bare Final without an assignment raises another diagnostic, but maybe this should be fixed anyway.

Code or Screenshots

from typing import ClassVar, reveal_type

class C:
    c: ClassVar

reveal_type(C.c)  # <- no diagnostic here

Playground link

Version information

Pyright 1.1.392

@sharkdp sharkdp added the bug Something isn't working label Jan 17, 2025
@erictraut
Copy link
Collaborator

Thanks for the bug report.

Pyright is not correctly handling a "bare" ClassVar qualifier. It's not clear from the spec whether this should be an error condition or treated implicitly as ClassVar[Any]. It appears that mypy does the latter, but I could make an argument for both behaviors. It would be good for the typing spec to be explicit about this. In any case, pyright should handle this better.

erictraut added a commit that referenced this issue Jan 18, 2025
…nnotation either with or without an assignment. This addresses #9720.
erictraut added a commit that referenced this issue Jan 18, 2025
…nnotation either with or without an assignment. This addresses #9720. (#9724)
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Jan 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants