<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 October 2017 at 02:14, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 14 October 2017 at 17:49, Ethan Furman wrote:<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem with PEP 560 is that it doesn't allow the class definition<br>
</blockquote></blockquote>
>> protections that a metaclass does.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since the discussion turned to PEP 560, I can say that I don't want this<br>
</blockquote>
> to be a general mechanism, the PEP rationale section gives several specific<br>
> examples why we don't want metaclasses to implement generic class<br>
> machinery/internals.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Could you please elaborate more what is wrong with PEP 560 and what do you<br>
</blockquote>
> mean by "class definition protections"<br>
<br>
Nothing is wrong with PEP 560.  What I am referring to is:<br>
<br>
class MyEnum(Enum):<br>
   red = 0<br>
   red = 1<br>
<br>
The Enum metaclass machinery will raise an error at the "red = 1" line because it detects the redefinition of "red". This check can only happen during class definition, so only the metaclass can do it.<br></blockquote><div><br></div>That's not necessarily an inherent restriction though - if we did decide to go even further in the direction of "How do we let base classes override semantics that currently require a custom metaclass?", then there's a fairly clear parallel between "mcl.__init__/bases.__init_subclass__" and "mcl.__prepare__/bases.__prepare_subclass__".</div><div class="gmail_quote"><br></div><div class="gmail_quote">OTOH, if you have multiple bases with competing __prepare__  methods you really *should* get a metaclass conflict, since the class body can only be executed in one namespace.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>