[Python-ideas] A way out of Meta-hell (was: A (meta)class algebra)

Nick Coghlan ncoghlan at gmail.com
Tue Feb 17 13:47:03 CET 2015


On 17 February 2015 at 08:27, Andrew Barnert
<abarnert at yahoo.com.dmarc.invalid> wrote:
> On Feb 16, 2015, at 8:19, Martin Teichmann <lkb.teichmann at gmail.com> wrote:
>
>> Hi list,
>>
>>> Again, Python already has a metaclass that everyone is supposed to
>>> use, namely `type`.
>>
>> well, there is a problem out here: people are indeed using other
>> metaclasses. Even the standard library, like ABC or enums.
>
> But almost all such metaclasses are instances (and direct subclasses, but that's not as important here) of type; I think he should have said "a type that everyone can usually use as a metaclass, and can at least pretty much always use as a metametaclass when that isn't appropriate".
>
> Anyway, for the problem you're trying to solve: there _is_ a real problem that there are a handful of popular metaclasses (in the stdlib, in PyQt, maybe elsewhere) that people other than the implementors often need to combine with other metaclasses, and that's hard, and unless PEP 422 makes all those metaclasses unnecessary, you still need a solution, right?

There *is* a way to combine instances of multiple metaclasses without
conflict: using composition ("has-a") rather than inheritance
("is-a"). A metaclass conflict can reasonably be described as a class
definition experiencing an unresolvable identity crisis by way of
trying to be too many different things at the same time :)

And if it's really 100% absolutely essential, then a custom subclass
of the relevant metaclasses can do the job. But the only "simple"
metaclass is "type", and that's really only considered simple because
it's the one we use by default, which means it's the baseline against
which the behaviour of all other metaclasses gets compared.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list