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 in the two places because the rules are different in 
the two places. (One case that *can* be made is that we should be throwing 
different exceptions or chaining them to show which metaclass resolution 
failed, rather than re-using the same message in both places).

This means that when you define a non-type metaclass hint, you're bypassing 
*all* of the PEP 3115 machinery, including the early metaclass resolution.

However, if your metaclass hint still creates a type instance, you're not 
bypassing tp_new.

If you're asking "Where is the bug in the presented example code?", it's here, 
in the definition of your metaclass hint:

    def metaclass_callable(name, bases, namespace):
        return OtherMetaclass(name, bases, namespace)

Instantiating instances of "type" directly in Python 3 bypasses the PEP 3115 
machinery - that's the entire reason that types.new_class was added. So if you 
want that metaclass hint to be PEP 3115 compliant, you need to explicitly write 
it that way:

    def metaclass_callable(name, bases, namespace):
        return types.new_class(name, bases, dict(metaclass=OtherMetaclass)

resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
title: Class definition is not consistent with types.new_class -> Documentation 
for handling of non-type metaclass hints is unclear

Python tracker <>
Python-bugs-list mailing list

Reply via email to