[Python-Dev] PEP 487 vs 422 (dynamic class decoration)

PJ Eby pje at telecommunity.com
Mon Apr 6 01:17:06 CEST 2015


On Sat, Apr 4, 2015 at 9:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> So actually reading https://gist.github.com/pjeby/75ca26f8d2a7a0c68e30
> properly, you're starting to convince me that a "noconflict" metaclass
> resolver would be a valuable and viable addition to the Python 3 type
> system machinery.
>
> The future possible language level enhancement would then be to make
> that automatic resolution of metaclass conflicts part of the *default*
> metaclass determination process. I realise you've been trying to
> explain that to me for a few days now, I'm just writing it out
> explicitly to make it clear I finally get it :)

I'm glad you got around to reading it.  Sometimes it's really
frustrating trying to get things like that across.

What's funny is that once I actually 1) wrote that version, and 2)
ended up doing a version of six's with_metaclass() function so I could
write 2/3 mixed code in DecoratorTools, I realized that there isn't
actually any reason why I can't write a Python 2 version of
noconflict.  Indeed, with a slight change to eliminate ClassType from
the metaclass candidate list, the Python 3 version would also work as
the Python 2 version: just use it as the explicit __metaclass__, or
use with_metaclass, i.e.:

    class something(base1, base2, ...):
        __metaclass__ = noconflict

        # ...

or:

    class something(with_metaclass(noconflict, base1, base2, ...)):
        # ...

And the latter works syntactically from Python 2.3 on up.


> My apologies for that - while I don't actually recall what I was
> thinking when I said it, I suspect I was all fired up that PEP 422 was
> definitely the right answer, and hence thought I'd have an official
> solution in place for you in fairly short order. I should have let you
> know explicitly when I started having doubts about it, so you could
> reassess your porting options.

Well, at least it's done now.  Clearing up the issue allowed me to
spend some time on porting some of the relevant libraries this
weekend, where I promptly ran into challenges with several of the
*other* features removed from Python 3 (like tuple arguments), but
fortunately those are issues more of syntactic convenience than
irreplaceable functionality.  ;-)


More information about the Python-Dev mailing list