On Wed, Jun 6, 2012 at 1:48 PM, PJ Eby <p...@telecommunity.com> wrote: > On Tue, Jun 5, 2012 at 8:14 PM, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
