[Python-Dev] PEP 560 vs metaclass' class definition protections [was Re: What is the design purpose of metaclasses ...] (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Oct 14 12:58:06 EDT 2017

On 15 October 2017 at 02:14, Ethan Furman <ethan at stoneleaf.us> wrote:

On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:

On 14 October 2017 at 17:49, Ethan Furman wrote:

The problem with PEP 560 is that it doesn't allow the class definition

>> protections that a metaclass does. Since the discussion turned to PEP 560, I can say that I don't want this > to be a general mechanism, the PEP rationale section gives several specific > examples why we don't want metaclasses to implement generic class > machinery/internals. Could you please elaborate more what is wrong with PEP 560 and what do you > mean by "class definition protections" Nothing is wrong with PEP 560. What I am referring to is: class MyEnum(Enum): red = 0 red = 1 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.

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

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.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171015/7ff55a2c/attachment.html>

More information about the Python-Dev mailing list