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

[Nick Coghlan]

On Wed, Jun 6, 2012 at 1:48 PM, PJ Eby <pje at telecommunity.com> wrote:
> On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> 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.
>
>
> Why not have type.__call__() do the invocation?  That is, why does it need
> to become part of the external class-building protocol?
>
> (One advantage to putting it all in type.__call__() is that you can emulate
> the protocol in older Pythons more easily than if it's part of the external
> class creation dance.)

That's something else I need to write up in the PEP (I *had* thought
about it, I just forgot to include the explanation for why it doesn't
work). The problems are two-fold:

1. It doesn't play nicely with __class__ (since the cell doesn't get
populated until after type.__call__ returns)
2. It doesn't play nicely with metaclass inheritance (when you call up
to type.__call__ from a subclass __call__ implementation, the dynamic
decorators will see a partially initialised class object)

That's really two aspects of the same underlying concern though: the
idea is that decorators should only be handed a fully initialised
class instance, which means they have to be invoked *after* the
metaclass invocation has already returned.

Cheers,
Nick.

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