Nick Coghlan wrote:
On Thu, May 10, 2012 at 6:11 PM, Mark Shannon <m...@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.
_______________________________________________
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
