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

Nick Coghlan ncoghlan at gmail.com
Tue Jun 5 04:25:34 CEST 2012

On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby <pje at telecommunity.com> wrote:

On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby <pje at telecommunity.com> wrote: > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan <ncoghlan at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list