On Wed, Jun 6, 2012 at 2:00 AM, Joao S. O. Bueno <jsbu...@python.org.br> wrote: > On 5 June 2012 09:24, Nick Coghlan <ncogh...@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 | 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
