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

[Nick Coghlan]

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