On Sun, May 20, 2012 at 11:03 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Sun, 20 May 2012 18:51:27 +1000 > Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
