On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby <p...@telecommunity.com> wrote: > On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby <p...@telecommunity.com> wrote: >> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> >> >> It's actually the pre-decoration class, since the cell is initialised >> >> before the class is passed to the first decorator. I agree it's a >> >> little >> >> weird, but I did try to describe it accurately in the new docs. >> > >> > I see that now; it might be helpful to explicitly call that out. >> > >> > This is adding to my list of Python 3 metaclass gripes, though. In >> > Python >> > 2, I have in-the-body-of-a-class decorators implemented using >> > metaclasses, >> > that will no longer work because of PEP 3115... >> >> I'm not quite following this one - do you mean they won't support >> __prepare__, won't play nicely with other metaclasses that implement >> __prepare__, or something else? > > > I mean that class-level __metaclass__ is no longer supported as of PEP 3115, > so I can't use that as a way to non-invasively obtain the enclosing class at > class creation time. > > (Unfortunately, I didn't realize until relatively recently that it wasn't > supported any more; the PEP itself doesn't say the functionality will be > removed. Otherwise, I'd have lobbied sooner for a better migration path.)
As in the "def __metaclass__(name, bases, ns): return type(name, bases, ns)" functionality? You can still pass an ordinary callable as the metaclass parameter and it will behave the same as the old class level __metaclass__ definition. I personally wouldn't be averse to bringing back the old spelling for the case where __prepare__ isn't needed - you're right that it's a convenient way to do a custom callable that gets inherited by subclasses. 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
