type(name, bases, dict) does not call metaclass' __prepare__ attribute

[nikratio]

BPO	18334
Nosy	@ncoghlan, @bitdancer, @berkerpeksag
Files	type_doc_patch.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-07-01.01:12:18.403>
labels = ['type-bug', 'docs']
title = "type(name, bases, dict) does not call metaclass' __prepare__ attribute"
updated_at = <Date 2016-08-03.15:12:05.069>
user = 'https://bugs.python.org/nikratio'

bugs.python.org fields:

activity = <Date 2016-08-03.15:12:05.069>
actor = 'berker.peksag'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2013-07-01.01:12:18.403>
creator = 'nikratio'
dependencies = []
files = ['30737']
hgrepos = []
issue_num = 18334
keywords = ['patch']
message_count = 5.0
messages = ['192099', '192100', '192101', '192102', '192113']
nosy_count = 5.0
nosy_names = ['ncoghlan', 'r.david.murray', 'nikratio', 'docs@python', 'berker.peksag']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue18334'
versions = ['Python 3.5', 'Python 3.6']

Linked PRs

• gh-62534: Document that three-argument type() does not call __prepare__ #154028
• [3.13] gh-62534: Document that three-argument type() does not call __prepare__ (GH-154028) #154164
• [3.15] gh-62534: Document that three-argument type() does not call __prepare__ (GH-154028) #154165
• [3.14] gh-62534: Document that three-argument type() does not call __prepare__ (GH-154028) #154166

[nikratio]

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.

[bitdancer]

"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.

[ncoghlan]

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).

[nikratio]

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.

[ncoghlan]

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".