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

[Martin Teichmann]

> 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 __new_subclass__ 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.