[Python-Dev] PEP 3135 (new super()) class references broken in 3.3 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun May 20 15:56:06 CEST 2012

On Sun, May 20, 2012 at 11:03 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sun, 20 May 2012 18:51:27 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote:

PEP 3135 defines the new zero-argument form of super() as implicitly equivalent to super(class, ), and up until 3.2 has behaved accordingly: if you accessed class from inside a method, you would receive a reference to the lexically containing class.

In 3.3, that currently doesn't work: you get NameError instead (http://bugs.python.org/issue14857) While the 3.2 behaviour wasn't documented in the language reference, it's definitely documented in PEP 3135 (and my recent updates to the 3.3 version of the metaclass docs were written accordingly - that's how I discovered the problem) The question is, do we want to support it? What's the use case?

Being able to deconstruct zero-argument super into something simpler (i.e. an implicit closure reference) makes it a lot more understandable, and lets people create their own variations on that theme rather than having it be completely opaque black magic (as it is now in 3.3).

If class had been covered by the test suite, then #12370 would never have been fixed the way it was.

However, while it isn't mentioned in the language reference (well, not until I added a mention of it yesterday), PEP 3135 itself was updated to say "Every function will have a cell named class that contains the class object that the function is defined in". The special variable is named as part of the specification section of the PEP. This contrasts with PEP 3115 and the build_class builtin, where the latter isn't mentioned in the PEP at all - it's just a CPython implementation artifact.

So this isn't a matter of "What's the use case for accessing class directly?" - it's a matter of "We broke backwards compatibility for a documented (albeit only in the originating PEP) feature and the test suite didn't pick it up".

Now, it isn't just a matter of reverting the old patch, because we need to bump the magic number for the bytecode again. But the fix for #12370 is broken, because it didn't just affect the class references at class scope - it also changed them all at method scope.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list