-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
Audit the correctness of adding parent.name to child's locals in ClassDef.__init__()
and FunctionDef.__init__()
#1490
Comments
Caused another false positive at pylint-dev/pylint#6895 |
I guess next step is to see what fails / depends on the current behavior. |
Commenting out the relevant lines crashes already in the bootstrapping of the I wonder if we can come up with some sort of rule for the cases where it shouldn't be added. Is there some sort of commonality between the currently identified cases? |
I think it might only be a "gotcha" when creating fake nodes in the brain. When creating a fake ClassDef from scratch in the namespace brain, there's no logical parent, since we don't have the argparse module -- we could probably get away with not setting a parent at all. |
We have deprecated |
ClassDef.__init__()
ClassDef.__init__()
and FunctionDef.__init__()
Same problem with inferring calls to This elaborate workaround is not observed when inferring a property: Lines 1246 to 1267 in ee2d4bd
|
Apparently, bugs can be caused by providing the
parent
argument toClassDef.__init__()
, because the name of that node (the ancestor) will be added to the locals of the child node, and this may not be intended (it wasn't intended in the case of subclassing anamedtuple
. We need to audit whether it is happening anywhere else and if that behavior is correct.See discussion at #1489 (comment).
The text was updated successfully, but these errors were encountered: