Nick Coghlan added the comment:
The "used directly as the metaclass" is a reference to
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object
further down, and specifically the "metaclass(name, bases, namespace, **kwds)"
call. It's not saying Python has a way to bypass th
Nick Coghlan added the comment:
Oops, couple of typos:
"... only triggers metaclass resolution at that point ..."
"... if either the metaclass being instantiated is a subclass of all the
metaclasses of all of the bases ..."
But the only way to bypass the "most derived metaclass" rule is for t
Neil Girdhar added the comment:
Okay, I understand what you're saying, but I it says in the documentation that
"if an explicit metaclass is given and it is not an instance of type(), then it
is used directly as the metaclass". My recent updated "metaclass_callable" is
not an instance of type.
Nick Coghlan added the comment:
Because they're checking for different things:
- types.prepare_class is only checking "How do I call __prepare__?". It only
triggers type resolution at that point if the metaclass hint is an instance of
type, otherwise it skips that process entirely and queries
Neil Girdhar added the comment:
Thanks for taking the time to explain, but it's still not working for me:
from types import new_class
class MyMetaclass(type):
pass
class OtherMetaclass(type):
pass
def metaclass_callable(name, bases, namespace):
return new_class(name, bases, dict(
Nick Coghlan added the comment:
Why should it trip the PEP 3115 namespace preparation exception? We only check
for __prepare__ (and hence need to do an early most-derived metaclass
resolution) on instances of "type", not on arbitrary callables used as a
metaclass hint
The checks are different