Audit the correctness of adding parent.name to child's locals in `ClassDef.__init__()` and `FunctionDef.__init__()`

[jacobtylerwalls]

Apparently, bugs can be caused by providing the parent argument to ClassDef.__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 a namedtuple. We need to audit whether it is happening anywhere else and if that behavior is correct.

See discussion at #1489 (comment).

[jacobtylerwalls]

Caused another false positive at pylint-dev/pylint#6895

[jacobtylerwalls]

I guess next step is to see what fails / depends on the current behavior.

[DanielNoord]

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 str ClassDef. So, it seems like this this is necessary for 90% of the cases.

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?

[jacobtylerwalls]

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.

[DanielNoord]

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 parent == None for any node other than nodes.Module. I think this is beneficial in pylint as it removes a lot of isinstance checks.