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

option to report possibly/conditionally uninitialized instance variables #977

Open
DetachHead opened this issue Jan 5, 2025 · 0 comments
Labels
type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules

Comments

@DetachHead
Copy link
Owner

DetachHead commented Jan 5, 2025

looks like this only works on top-level statements:

class C:
    x: int # error

    def __init__(self) -> None:
        if bool():
            self.reset()
        else:
            self.reset()

though this may be difficult to correctly fix. for example if we were to copy the current behavior pyright uses to check for assignments in __init__ it would also be incorrect:

class C:
    x: int # no error, even though x is never assigned

    def __init__(self) -> None:
        if bool():
            self.x = 3

i think we would need to analyze the flow to address this properly. i havent yet touched that part of the pyright codebase so i have no idea what the best way to do this would be, so maybe we can just keep the behavior you have for now and create a follow-up issue for this.

Originally posted by @DetachHead in #975 (comment)

@DetachHead DetachHead added the type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules label Jan 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules
Projects
None yet
Development

No branches or pull requests

1 participant