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

Martin Teichmann lkb.teichmann at gmail.com
Tue Feb 17 16:19:04 CET 2015

But if you did have a merging mechanism, would it solve this problem? To work properly, the merge mechanism in the new metaclass would have to check that it's dealing with the PyQt metaclass, wouldn't it? How whould that check work if the PyQt metaclass is not available?

Well, both would inherit from the same baseclass, let's call it SimpleMixable, or AbstractMetaclass. This will now mix the two classes. (In Nick's words: "You're asking us to assume covariant metaclasses in a subset of cases, while retaining the assumption of contravariance otherwise.") If PyQt doesn't want to inherit from AbstractMetaclass, it can later be registered by

AbstractMetaclass.register(PyQt4.QtMetaclass)

I don't quite get the example. Why would you want an ABC that is a QObject?

well, imagine you have an ABC called WindowABC that defines abstract methods that apply to a window, then you could write a class

class Window(WindowABC, QWindow):
     # add some code here

which creates a concrete class implementing the WindowABC. The documentation states about this: "An ABC can be subclassed directly, and then acts as a mix-in class."

- a newsubclass as a replacement for the metaclass new. This shows that it is necessary to operate on subclasses, otherwise one will have a hard time to create the class itself... Well, super() cooperative inheritance won't help if you really need different types of objects, rather than differently initialized objects. This pretty much needs the full power of metaclasses.

It doesn't. In the test code that I posted to github there is the example:

class A(Object):
    @staticmethod
    def __new_subclass__(name, bases, dict):
        return 3
class B(A):
    pass
self.assertEqual(B, 3)

it already works.

Such a decorator isn't terribly hard to write today.

Done.

More information about the Python-ideas mailing list