(original) (raw)

On 15 October 2017 at 02:14, Ethan Furman <ethan@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@gmail.com | Brisbane, Australia