When using the three parameter form of type to create a new class, and any of the base classes has a metaclass with a __prepare__ function, the __prepare__ function is not executed:


      >>> class CustomMetaclass(type):
      ...     @classmethod
      ...     def __prepare__(cls, name, bases):
      ...          return { 'prepared_for': name }
      ...
      >>> class ParentClass(metaclass=CustomMetaclass):
      ...     pass
      ...
      >>> class ClassOne(ParentClass):
      ...     pass
      ...
      >>> ClassTwo = type('ClassTwo', (ParentClass,), {})
      >>> ClassOne.prepared_for
      'ClassOne'
      >>> ClassTwo.prepared_for
      'ParentClass'
      >>> 'prepared_for' in ClassOne.__dict__
      True
      >>> 'prepared_for' in ClassTwo.__dict__
      False


I am not sure if that is intended behavior or not. I am attaching a doc patch for the case that this is intended.

"Intentional" is not perhaps the exactly right term, but it is working as expected.  There was a thread about this on python-dev ("PEP 3115 compliant dynamic type creation" and "adding types.build_class for 3.3"), that ultimately resulted in the addition of the 'new_class' function to the types module.  The documentation should probably just say that types doesn't handle metaclass __prepare__, and provide a link to the new_class function.

I think we should actually go further, and explicitly defer to http://docs.python.org/3/library/types#dynamic-type-creation for dynamic type creation.

Type shouldn't be called with arbitrary bases any more, precisely *because* doing so breaks __prepare__ handling. It's only safe to call a metaclass directly with arbitrary bases if you call types.prepare_class first:

    mcl, namespace, kwds = types.prepare_class(name, bases)
    cls = mcl(name, bases, namespace, **kwds)

You can only skip types.prepare_class if you *know* you already have the right metaclass (such as when there aren't any base classes defined).

In that cases, maybe type(name, cls, clsdict) should actually raise an error if there's a metaclass with __prepare__ involved?

Presumably that would break only code that was already broken, but it would convert previously hidden behavioral bugs into an explicit expressions raised at the right point.

Unfortunately, it's not that simple, as calling type(name, bases, namespace) is *exactly* what a subclass will do as part of creating the type object.

From inside the type implementation, we can't tell the difference between "properly called from the child type" and "improperly called without preparing the namespace first".