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

PJ Eby pje at telecommunity.com
Wed Jun 6 17:39:07 CEST 2012


On Wed, Jun 6, 2012 at 5:31 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Wed, Jun 6, 2012 at 5:09 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On Wed, Jun 6, 2012 at 1:28 AM, PJ Eby <pje at telecommunity.com> wrote:
> >> To be clear, what I specifically proposed (as I mentioned in an earlier
> >> thread) was simply to patch __build_class__ in order to restore the
> missing
> >> __metaclass__ hook.  (Which, incidentally, would make ALL code using
> >> __metaclass__ cross-version compatible between 2.x and 3.x: a
> potentially
> >> valuable thing in and of itself!)
> >>
> >> As for metaclasses being hard to compose, PEP 422 is definitely a step
> in
> >> the right direction.  (Automatic metaclass combining is about the only
> thing
> >> that would improve it any further.)
> >
> > Just as a warning, I doubt I'll be able to persuade enough people that
> > this is a feature worth including in the short time left before 3.3
> > feature freeze. It may end up being necessary to publish metaclass
> > and explicit decorator based variants (with their known limitations),
> > with a view to gaining support for inclusion in 3.4.
>
> Upgrading this warning to a fact: there's no way this topic can be
> given the consideration it deserves in the space of the next three
> weeks. I'll be changing the title of 422, spend more time discussing
> the problem (rather than leaping to a conclusion) and retargeting the
> PEP at 3.4.
>
> If you do decide to play around with monkeypatching __build_class__,
> please make clear to any users that it's a temporary fix until
> something more robust and less implementation dependent can be devised
> for 3.4.
>

Ideally, I would actually implement it as a backport of the PEP...  in
which case I suppose making it part of the class creation machinery (vs.
embedding it in type.__call__ or some place like that) will make that
process easier.

Again, as I said earlier, I'm talking about this now because there was
related discussion now, not because I'm actively trying to port my
libraries.  At this point, I've only done a few "make this library usable
from 3.x as-is" changes by user request, for some of my smaller libraries
that were mostly there already (e.g. simplegeneric).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120606/7d4b0290/attachment.html>


More information about the Python-Dev mailing list