[Python-Dev] Adding types.build_class for 3.3 (original) (raw)

Mark Shannon mark at hotpy.org
Thu May 10 11:51:46 CEST 2012

Nick Coghlan wrote:

On Thu, May 10, 2012 at 6:11 PM, Mark Shannon <mark at hotpy.org> wrote:

Finally, could you remind me how the proposed type.define differs from builtins.buildclass? I can't see any difference (apart from parameter ordering and the extra name parameter in builtins.buildclass). It's the officially supported version of that API - the current version is solely a CPython implementation detail. The main change is moving execbody to the end and making it optional, thus bringing the interface more in line with calling a metaclass directly. The name parameter is actually still there, I just forgot to include in the examples in the thread. You'll find there's no mention of buildclass in the language or library references, thus there's currently no official way to programmatically define a new type in a way that complies with PEP 3115. (This is explained in the tracker issue and the previous thread that proposed the name operator.buildclass)

I prefer type.define(), but if the descriptor protocol does cause problems (and making static methods callable doesn't fix them), then we'll move it somewhere else (probably types.define() with a new types module).

The problem with any non-overriding descriptor bound to type is that when accessed as type.define it acts as a descriptor, but when accessed from any other class, say int.define it acts as a non-overriding meta-descriptor; c.f. type.mro() vs int.mro()

To avoid this problem, type.define needs to be an overriding descriptor such as a property (a PyGetSetDef in C). Alternatively, just make 'define' a non-descriptor. It would unusual (unique?) to have a builtin-function (rather than a method-descriptor) bound to a class, but I can't see any fundamental reason not to.

Cheers, Mark.

More information about the Python-Dev mailing list