[Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

[Nick Coghlan]

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__, <first argument>), 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