[Python-Dev] PEP 560 vs metaclass' class definition protections [was Re: What is the design purpose of metaclasses ...]
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