<div dir="ltr">You're right that if it were easier to combine metaclasses we would not shy away from them so easily.<div><br></div><div>Perhaps you and others interested in this topic can try to prototype an implementation and see how it would work in practice (with some realistic existing metaclasses)? Then the next step would be to write a PEP. But in this case I really recommend trying to implement it first (in pure Python) to see if it can actually work.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 12, 2017 at 11:21 AM, Martin Teichmann <span dir="ltr"><<a href="mailto:lkb.teichmann@gmail.com" target="_blank">lkb.teichmann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi list,<br>
<br>
first, a big thanks to the authors of PEP 557! Great idea!<br>
<br>
For me, the dataclasses were a typical example for inheritance, to be<br>
more precise, for metaclasses. I was astonished to see them<br>
implemented using decorators, and I was not the only one, citing<br>
Guido:<br>
<span class=""><br>
> I think it would be useful to write 1-2 sentences about the problem with<br>
> inheritance -- in that case you pretty much have to use a metaclass, and the<br>
> use of a metaclass makes life harder for people who want to use their own<br>
> metaclass (since metaclasses don't combine without some manual<br>
> intervention).<br>
<br>
</span>Python is at a weird point here. At about every new release of Python,<br>
a new idea shows up that could be easily solved using metaclasses, yet<br>
every time we hesitate to use them, because of said necessary manual<br>
intervention for metaclass combination.<br>
<br>
So I think we have two options now: We could deprecate metaclasses,<br>
going down routes like PEP 487's __init_subclass__. Unfortunately, for<br>
data classes __init_subclass__ it is too late in the class creation<br>
process for it to influence the __slots__ mechanism. A<br>
__new_subclass__, that acts earlier, could do the job, but to me that<br>
simply sounds like reinventing the wheel of metaclasses.<br>
<br>
The other option would be to simply make metaclasses work properly. We<br>
would just have to define a way to automatically combine metaclasses.<br>
Guido once mention once (here:<br>
<a href="https://mail.python.org/pipermail/python-dev/2017-June/148501.html" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>pipermail/python-dev/2017-<wbr>June/148501.html</a>)<br>
that he left out automatic synthesis of combined metaclasses on<br>
purpose, but given that this seems to be a major problem, I think it<br>
is about time to overthink this decision.<br>
<br>
So I propose to add such an automatic synthesis. My idea is that a<br>
metaclass author can define the __or__ and __ror__ methods for<br>
automatic metaclass synthesis. Then if a class C inherits from two<br>
classes A and B with metaclasses MetaA and MetaB, the metaclass would<br>
be MetaA | MetaB.<br>
<br>
Greetings<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>