Pull Request Test Coverage Report for Build 2044799690

• 2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.0009%) to 91.489%

Totals
Change from base Build 2039365401:	0.0009%
Covered Lines:	9083
Relevant Lines:	9928

💛 - Coveralls

I'm going to release the hot fix in 2.11.2 / 2.13.2, when @DanielNoord is available for review we can integrate his review in 2.12.

I'm not sure this is correct. Doesn't this code check something tricky?

from collections import namedtuple

class X(namedtuple("X", ["a", "b", "c"])):
    pass

I believe X should be in the locals of the ClassDef as that X is referring to NamedTuple X.

For:

from collections import namedtuple

class Y(namedtuple("X", ["a", "b", "c"])):
    pass

X should also be in the locals of Y.

(Pdb) klass.locals
{'__module__': [<Const.str l.4 at 0x10ebbfa30>], '__qualname__': [<Const.str l.4 at 0x10ebbf940>], 'X': [<ClassDef.X l.4 at 0x10ebbfb80>]}
(Pdb) klass
<ClassDef.X l.4 at 0x10ebbfd60>
(Pdb) klass.locals["X"]
[<ClassDef.X l.4 at 0x10ebbfb80>]
(Pdb) klass.locals["X"] == klass
False

Note that these are two different ClassDefs. Their address doesn't match.

Yes, they are different ClassDefs. But why should the name of the parent class be in the child class's locals? It's not even in the parent class's locals, is it?

>>> X = namedtuple("X", [])
>>> 'X' in dir(X)
False

So why would we want 'X' to be in the locals of Y when it's not even in X?

Yes, they are different ClassDefs. But why should the name of the parent class be in the child class's locals? It's not even in the parent class's locals, is it?

>>> X = namedtuple("X", [])
>>> 'X' in dir(X)
False

So why would we want 'X' to be in the locals of Y when it's not even in X?

Ah yeah, didn't think about that.

It's getting late here, but are there any other examples where something gets defined in the "ancestors space" of a class definition? Do we add them as well?
I guess the fix is actually correct then, but it does feel a bit weird. Like, wouldn't it be better to handle this in the __init__ instead of arbitrary not passing parent?

Like, wouldn't it be better to handle this in the init instead of arbitrary not passing parent?

Oh it definitely feels janky. I was just trying to restore status quo before the commit that caused the failure. You're right this could be audited and fixed in the __init__.

Would you mind opening an issue for it? Then at least we don't forget about it :)

done!