[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 08:54:29 CEST 2012

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

More information about the Python-Dev mailing list