Ethan Furman added the comment:
As David noted, this was discussed somewhere in the megathreads that was the
Enum PEP discussion.
As Georg noted changes to such a thoroughly discussed API should not be taken
lightly.
As Antoine noted the Enum class is more restricted than normal classes by
Roundup Robot added the comment:
New changeset 54ddd1124df8 by Ethan Furman in branch 'default':
Close #18989: enum members will no longer overwrite other attributes, nor be
overwritten by them.
http://hg.python.org/cpython/rev/54ddd1124df8
--
nosy: +python-dev
resolution: - fixed
Georg Brandl added the comment:
It can be changed up to beta1, with good reasons of course. Many PEPs are
actually out of date with respect to the actual implementation in minor points.
--
nosy: +georg.brandl
___
Python tracker
Georg Brandl added the comment:
That said, for a PEP that has seen so much discussion before being accepted,
the agreed-on API should not be changed lightly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
Antoine Pitrou added the comment:
Le samedi 14 septembre 2013 à 07:03 +, Georg Brandl a écrit :
Georg Brandl added the comment:
That said, for a PEP that has seen so much discussion before being
accepted, the agreed-on API should not be changed lightly.
I agree with that.
Also, I think
Eli Bendersky added the comment:
On Fri, Sep 13, 2013 at 7:11 PM, Nick Coghlan rep...@bugs.python.orgwrote:
Nick Coghlan added the comment:
+1 from me to just allow the names to be overwritten, even by another enum
member.
Even though I was in favor of this in the initial discussions
Nick Coghlan added the comment:
OK, rechecking PEP 435, I see that disallowing reuse of a name was indeed
explicitly accepted as part of the defined API:
http://www.python.org/dev/peps/pep-0435/#duplicating-enum-members-and-values
In that case, I switch my perspective to agree with Ethan that
Eli Bendersky added the comment:
I agree with David. This is yet another case where we try to go against Python
and make enum special, and I'm against this. Nothing prevents users from
accidentally overriding their own members and methods in normal classes as
well. This is trivially
Antoine Pitrou added the comment:
What if I redefine an existing key inside a subclass?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
Ethan Furman added the comment:
One cannot subclass an Enum that has already defined keys.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
Ethan Furman added the comment:
Perhaps you meant, what if you define a key in a subclass that shadows a
method/property in a parent class?
I'm inclined to say that would be acceptable, since one reason for subclassing
is to add or make changes to the parent class' behavior.
--
Ethan Furman added the comment:
In any other (normal) class, this works:
==
--class Okay:
... red = 1
... green = 2
... blue = 3
... red = 4
Nick Coghlan added the comment:
+1 from me to just allow the names to be overwritten, even by another enum
member.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
Ethan Furman added the comment:
That is expressly forbidden in the PEP. Can we change it now?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
New submission from Ethan Furman:
Consider:
==
--from enum import Enum
--class Color(Enum):
... red = 1
... green = 2
... blue = 3
... red = 4
...
Traceback (most recent call last):
File stdin, line 1,
R. David Murray added the comment:
As I recall this was discussed at length and we decided that this was the
behavior we wanted. I could be wrong, of course; it was a long discussion.
--
nosy: +r.david.murray
___
Python tracker
Nick Coghlan added the comment:
I don't recall this *particular* wrinkle being discussed. Silently failing
to define one of the requested enum members seems quite dubious.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
17 matches
Mail list logo
