[Python-Dev] Python 3, new-style classes and class (original) (raw)

Guido van Rossum guido at python.org
Mon Nov 21 19:42:31 CET 2011

On Mon, Nov 21, 2011 at 9:22 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

On 20/11/2011 21:41, Guido van Rossum wrote:

On Sun, Nov 20, 2011 at 10:44 AM, Michael Foord <fuzzyman at voidspace.org.uk>  wrote:

On 20 Nov 2011, at 16:35, Guido van Rossum wrote:

Um, what?! class already has a special meaning. Those examples violate that meaning. No wonder they get garbage results.

The correct way to override isinstance is explained here: http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass .

Proxy classes have been using class as a descriptor for this purpose for years before ABCs were introduced. This worked fine up until Python 3 where the compiler magic broke it when super is used. That is now fixed anyway. Hm, okay. Though it's disheartening that it took three releases of 3.x to figure this out. And there was a PEP even! If I understand correctly, ABCs are great for allowing classes of objects to pass isinstance checks (etc) - what proxy, lazy and mock objects need is to be able to allow individual instances to pass different isinstance checks. Ah, oops. Yes, instancecheck is for the class to override isinstance(inst, cls); for the instance to override apparently you'll need to mess with class. I guess my request at this point would be to replace '@class' with some other legal identifier that doesn't clash with existing use -- I don't like the arbitrary use of @ here. The problem with using a valid identifier name is that it leaves open the possibility of the same "broken" behaviour (removing from the class namespace) for whatever name we pick. That means we should document the name used - and it's then more likely that users will start to rely on this odd (but documented) internal implementation detail. This in turn puts a burden on other implementations to use the same mechanism, even if this is less than ideal for them. This is why a deliberately invalid identifier was picked.

Hm. There are many, many places in Python where a special identifier is used in such a way that a user who stomps on it can cause themselves pain. This is why the language reference is quite serious about reserving all special names and states that only documented uses of them are allowed (and at least implying that undocumented uses are not necessarily flagged as errors).

While I see that PEP 3119 made a mistake in giving class two different, incompatible special uses, I don't agree that this case is so special that we should use an "invalid" identifier. I don't see that the name use should actually be documented -- users should not make any use of undocumented names. Let's please continue the tradition of allowing experts to mess around creatively with internals.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list