[Python-Dev] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Jun 6 02:14:44 CEST 2012

On Wed, Jun 6, 2012 at 2:00 AM, Joao S. O. Bueno <jsbueno at python.org.br> wrote:

On 5 June 2012 09:24, Nick Coghlan <ncoghlan at gmail.com> wrote:

PEP written and posted: http://www.python.org/dev/peps/pep-0422/ More toy examples here: https://bitbucket.org/ncoghlan/misc/src/default/pep422.py Yes, it means requiring the use of a specific metaclass in 3.2 (either directly or via inheritance), but monkeypatching an undocumented builtin is going to pathological lengths just to avoid requiring that people explicitly interoperate with your particular metaclass mechanisms. When reading the PEP, I got the impression that having a "decorate" method on "type", which would perform its thing, would be not add magic exceptions, would be more explicit and more flexible than having an extra step to be called between the metaclass execution and decorator applying. So, I think that settling for having the decorators applied - as described in the PEP - in a decorate method of the metaclass would be nicer and cleaner.

On reflection, I'm actually inclined to agree. The next version of the PEP will propose the addition of type.decorate(). This new method will be invoked after the class is created and the class cell is populated, but before lexical decorators are applied.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list