Greg Turner added the comment:
> perhaps "isinstance(x, type)" should have been "issubclass(x, type)" to
> correctly capture how python 2 does it.
Actually, scratch that -- its a brain fart.
IIUC new_class was created because, at the time, there was no exposed turnkey
method to execute the PEP3115 protocol... if that's right, is it worth
considering, now that __build_class__ is exposed, a reimplementation like:
def _pass(ns): pass
def new_class(name, bases=(), kwds={}, exec_body=_pass):
__build_class__(exec_body, name, *bases, **kwds)
? But this is the wrong place to ask.
...
BTW, since my original post I've figured out a bunch of things, or think I have:
* new_class should model __build_class__
* __build_class__ need not model type_new in terms of what it allows.
I think point one is what was confusing me before.
It is perhaps worth asking, if the differences between type_new and
__build_class__ make sense, given that python 3's type_new is stricter than
python 2's? I think I've figured that out too:
A given (metatype, bases) tuple may be sensibly used to implement the PEP3115
protocol only if either:
A) it can be proved that type_new will return NULL if it
is invoked like type_new(metatype, name, bases,...), or,
B) it can be proved that type_new, when invoked like
type_new(metatype, name, bases, ...), will use metatype,
and not some other (e.g., more derived) type, as the tp_base
of the thing it creates, in the event that it does not return NULL.
If the above is falsified, we pretty clearly have a situation where build_type
has used the wrong metaclass.
But the fact that __build_class__ is more liberal than type_new is not a
problem from the perspective of type_new -- indeed it's a feature, and I'm now
satisfied that the above constraint holds.
I've attached a new patch, this time I tested it.
----------
Added file: http://bugs.python.org/file37348/fix_types_calculate_meta_v2.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22968>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
