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

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ethan Furman]

Changes by Ethan Furman et...@stoneleaf.us:


--
nosy:  -ethan.furman

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ethan Furman]

Changes by Ethan Furman et...@stoneleaf.us:


--
nosy: +ethan.furman

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nikolaus Rath]

New submission from Nikolaus Rath:

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.

--
components: Interpreter Core
files: type_doc_patch.diff
keywords: patch
messages: 192099
nosy: Nikratio
priority: normal
severity: normal
status: open
title: type(name, bases, dict) does not call metaclass' __prepare__ attribute
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30737/type_doc_patch.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

R. David Murray added the comment:

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.

--
assignee:  - docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, ncoghlan, r.david.murray
versions: +Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

Nick Coghlan added the comment:

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nikolaus Rath]

Nikolaus Rath added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18334
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com