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

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