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.__build_class__? >> I can't see any difference (apart from parameter ordering and the extra name >> parameter in builtins.__build_class__). > > It's the officially supported version of that API - the current > version is solely a CPython implementation detail. The main change is > moving exec_body 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 __build_class__ 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.build_class) > > 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4