-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
False no-member positive on defaultless instance variables on subclasses #3167
Comments
Yeah, I think |
You get the same error if class A:
myfield: int
def get_myfield(self):
return self.myfield # no-member |
That is right, because myfield is static and can only be accessed with |
I think you are mistaken on two accounts here:
|
Yes, that is right. That was actually an instance variable annotation. Class variables are supposed to use the class A:
myclassvar: ClassVar[int] I do think that the chosen syntax has resulted in some confusion, but it is what it is. |
As a workaround, you can assign the instance variable in a class A:
myvar: int
def __init__(self):
if False # pylint: disable=using-constant-test
self.myvar = 42 Ick. But at least it saves you from having to add pylint comments anywhere the If anyone knows a better workaround, I would love to hear it. |
@PCManticore Is there any movement on resolving the scenario in the original issue? We are running into this issue on a daily basis. 🙂 |
This issue causes us to either use improper typing and assign a None default and constantly make sure that it is asserted to satisfy type checking, or ignore about every line to either satisfy type checking or pylint. It is rather sad, as it really degrades the whole goal of these tools in the first place. It has been a frustrating experience. Really hope that this can be picked up by someone 😢 |
I opened #4194 to fix this issue |
t.py:
Pylint doesn't appear to "see" the subclass
myfield
member declared in the parent class (reports the error againstB
), but does see it in the parent class (doesn't report againstA
).(Technically I suppose the member isn't actually there in the parent class either as it's an instance variable without a default [1], and I believe they kind of spring to life only when actually set to a value which doesn't happen in this example -- for this reason the example code actually raises when run. Pylint seems to "know" that it's (or will be) there nevertheless which I think is great, but it should also know that it's there in the subclass.
[1] https://www.python.org/dev/peps/pep-0526/#class-and-instance-variable-annotations)
The text was updated successfully, but these errors were encountered: