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

[Andrew Barnert]

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?

Maybe the answer is not a generic way of combining any two metaclasses, but some way for the author of a metaclass to make it more easily combinable. Whether that's a decorator, a metametaclass, or something even more complicated, I think you'd have an easier time convincing people of its utility: if you're writing a metaclass like Qt's, use this and other people can subclass your metaclass just by doing X instead of having to do Y. The fact that it also happens to work in a wider variety of cases is nice, but not the selling point. (But it can hardly be used as an argument against your design--any decorator can be used to monkey patch a function or class after the fact; any ABC can be registered after the fact; etc. That's a normal part of Python.) However, if it can be used to more easily backport PEP 422 code, that _is_ a selling point, of course.

> And there is a problem here in python: once you do multiple inheritance,
> and two classes have different metaclasses, there is no way of
> programmatically determining an appropriate metaclass.
> 
> Sure, one can be of Thomas' opinion that doing so is a bad idea
> anyways, but there are other people who think that writing and
> combining metaclasses actually is thing one can do.
> 
> Especially for simple cases I do think that metaclasses are a good
> idea and there should be a way to tell python how to combine two
> metaclasses.
> 
> I am trying to solve this problem. What I posted was just one simple
> idea how to solve it. Another one is the idea I posted earlier, the
> idea was to add metaclasses using __add__. People didn't like the
> __add__, so I implemented that with a new method called merge,
> it's here: https://github.com/tecki/cpython/commits/metaclass-merge
> 
> Instead of yelling at me that my solutions are too complicated,
> it would be very helpful and constructive to answer the following
> questions:
> 
> - is it desirable to have a programmatic way to combine metaclasses?
> - if yes, how should that be done?
> 
> My idea is that yes, it is desirable to have a programmatic way of
> combining metaclasses, and I have now proposed two ways how to
> do that.
> 
> Greetings
> 
> Martin
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/