Okay. How about this then: class MM(type):     def __subclasscheck__(self, subclass):         return issubclass(subclass, type) class M(type, metaclass=MM):     pass class N(type):     pass class C(metaclass=M):     pass class D(metaclass=N):     pass class E(C, D, metaclass=N):     pass def main():     assert type(E) is N and issubclass(E, C) main() On 2019-12-31 3:16 p.m., Anders Hovmöller wrote:

You forgot something in that example I think because it doesn't actually do anything that can "not work".

...

On 31 Dec 2019, at 18:41, Soni L. wrote:

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses:

class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type)

class M(type, metaclass=MM): pass

class N(type): pass

class C(metaclass=M): pass

class D(metaclass=N): pass

class E(C, D, metaclass=N): pass

def main(): e = E()

main() _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4F6IQD... Code of Conduct: http://python.org/psf/codeofconduct/

Yes. That's my point. I don't like that error. On 2019-12-31 3:23 p.m., Anders Hovmöller wrote:

Tried that. Got:

TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

You should probably try the example you're trying to post before posting it.

...

On 31 Dec 2019, at 19:19, Soni L. wrote:

Okay. How about this then:

class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type)

class M(type, metaclass=MM): pass

class N(type): pass

class C(metaclass=M): pass

class D(metaclass=N): pass

class E(C, D, metaclass=N): pass

def main(): assert type(E) is N and issubclass(E, C)

main()

...

On 2019-12-31 3:16 p.m., Anders Hovmöller wrote: You forgot something in that example I think because it doesn't actually do anything that can "not work".

...

On 31 Dec 2019, at 18:41, Soni L. wrote:

...

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses: class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type)

...

class M(type, metaclass=MM): pass class N(type): pass class C(metaclass=M): pass class D(metaclass=N): pass class E(C, D, metaclass=N): pass def main(): e = E() main()

---

Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4F6IQD... Code of Conduct: http://python.org/psf/codeofconduct/

On 2019-12-31 3:56 p.m., Andrew Barnert wrote:

On Dec 31, 2019, at 09:43, Soni L. wrote:

...

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses:

class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type)

class M(type, metaclass=MM): pass

class N(type): pass

class C(metaclass=M): pass

class D(metaclass=N): pass

class E(C, D, metaclass=N): pass

Is the problem you’re trying to solve here, that you want to be able to override the metaclass conflict check in class definitions, so you can allow this?

If so, I think it makes sense. N is (trivially) a subclass of the N (the metaclass of D), and you’re making it a virtual subclass (via MM) of M (the metaclass of C). So there actually is no conflict if you take virtual subclasses into account; N is unambiguously the most derived metaclass.

(I suppose it would be ambiguous again if you also made M a (virtual or direct) subclass of N, but that’s probably consulting-adults territory: don’t do that, and if you do, the fact that the error message isn’t as meaningful as it could be isn’t a huge deal.)

But you said “many places”. Is there a wider class of places, that includes the metaclass conflict check, where virtual subclassing is ignored but (you think) shouldn’t be?

In the documentation for metaclass stuff, Python mentions "subtype" without referring to issubtype. I assume other parts of the docs also do similar things, but I haven't checked. However, I can imagine cases where virtual subtypes would cause problems. Namely, the C API and builtins. But, more importantly, it wouldn't work there anyway since you can't monkeypatch __instancecheck__ / __subclasscheck__ of built-ins in the first place. So, in practice, I can't imagine a case where virtual subclasses would be a problem.

On 2019-12-31 4:28 p.m., Andrew Barnert wrote:

On Dec 31, 2019, at 11:02, Soni L. wrote:

...

...

On 2019-12-31 3:56 p.m., Andrew Barnert wrote: On Dec 31, 2019, at 09:43, Soni L. wrote:

...

...

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses: class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type)

...

class M(type, metaclass=MM): pass class N(type): pass class C(metaclass=M): pass class D(metaclass=N): pass class E(C, D, metaclass=N): pass

Is the problem you’re trying to solve here, that you want to be able to override the metaclass conflict check in class definitions, so you can allow this?

If so, I think it makes sense. N is (trivially) a subclass of the N (the metaclass of D), and you’re making it a virtual subclass (via MM) of M (the metaclass of C). So there actually is no conflict if you take virtual subclasses into account; N is unambiguously the most derived metaclass.

(I suppose it would be ambiguous again if you also made M a (virtual or direct) subclass of N, but that’s probably consulting-adults territory: don’t do that, and if you do, the fact that the error message isn’t as meaningful as it could be isn’t a huge deal.)

But you said “many places”. Is there a wider class of places, that includes the metaclass conflict check, where virtual subclassing is ignored but (you think) shouldn’t be?

In the documentation for metaclass stuff, Python mentions "subtype" without referring to issubtype. I assume other parts of the docs also do similar things, but I haven't checked.

Well, there is no “issubtype”; only “issubclass”. Just like there is no “virtual subtype”, only “virtual subclass”.

I think the docs may be deliberately using “subtype” rather than “subclass” for that reason. But if so, it isn’t exactly clear, because I don’t think “subtype” is actually defined anywhere, and “direct or indirect, but not virtual, subclass” certainly isn’t the only meaningful guess you could make. This is probably worth filing a docs bug on even if nothing else is changed to clarify what that’s supposed to mean. (With your change, the docs probably just need to change to say subclass.)

I only see the word “subtype” a few other times, and they’re all declaring that some builtin is a subtype or some other thing, so it doesn’t matter whether it’s supposed to mean “subclass” or “non-virtual subclass” or some other thing. But I haven’t searched exhaustively.

But meanwhile, even if you do fix this here, would it actually help? It would mean the interpreter can determine the most derived metaclass unambiguously, so it would call N.__prepare__ and eventually N('E', (C, D), {…stuff…}). Which would be fine if you overrode __new__ or meta __call__ or didn’t inherit from type, but you don’t do any of those, so that just calls type.__new__. And (again, I haven’t tested any of this…) doesn’t type.__new__ also need to work out the most derived subtype again? Or does that already work?

And then, even if that works, wouldn’t that make it do things like call N.__init_subclass__(C) instead of type(C).__init_subclass__(C)? (That’s an abbreviation for the special method lookup rules, not literal code. And again, I haven’t tested any of this, so maybe I’m being stupid.)

Why would it call N.__init_subclass__(C), or type(C).__init_subclass__(C) for that matter? __init_subclass__ goes on the baseclass, not metaclass. And uh, I don't think customizing the actual class instance for the parent class means you can't drop that customization for child classes. For what it's worth, I do want to override meta __call__ actually, and only that. Only because, currently, you can't just override __new__ as it'd lead to __init__ being called twice for e.g. the E() in M(E()), if you wanted to return it from __new__ for some reason. How can you have multiple inheritance, and have a magic __call__ on the parent class (but not keep it - or at least not keep its behaviour, if no metaclass is explicitly specified - for subclasses)? Currently it doesn't seem like you can.

...

However, I can imagine cases where virtual subtypes would cause problems. Namely, the C API and builtins. But, more importantly, it wouldn't work there anyway since you can't monkeypatch __instancecheck__ / __subclasscheck__ of built-ins in the first place.

I didn’t think of that. But you don’t have to monkeypatch them to hot that problem, you can write your own extension module with a class that defines __subclasscheck__, and what happens then? (Although consenting adults seems even more relevant here—as long as the answer isn’t “segfault without diagnostics”, whatever happens is probably fine…)