[issue18989] reuse of enum names in class creation inconsistent
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 design. As Nick seconded the current situation is thoroughly confusing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 it was argued that Enums are by design restricted classes in that they forbid certain things in the name of convenience and expectability. I think it is a reasonable design point and, as such, Enums needn't be as flexible and versatile as normal classes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 (obviously, as I'm generally in favor of Enum being less magic and special) and had to agree with the consensus, I think it's too late now - unless we want to reopen the pandora box. Otherwise, it would not be fair, IMHO. In the original discussions a lot of people gave their opinions and had the context to chime in - now changing this quietly in the bug tracker with only a handful of participants isn't appropriate. The current behavior is fine, I think. The vast majority of enums will not have methods, and some amount of safety against typos in member definitions makes sense. Methods have other rules anyway (such as being definable in subclasses), and since their uses are rarer and arguably more deliberate, leaving them with more a Pythonic nature should be fine. This behavior is documented in the PEP and documentation and is fairly well understood. Also, we can always lift restrictions later without breaking existing code, if it's deemed that some restrictions are too much. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 overwriting it
with a method or descriptor should *also* be disallowed. The PEP is currently
silent on that question, and as Ethan notes in the original post, the weird
middle ground of the current behaviour is thoroughly confusing:
class Disallowed(Enum):
... a = 1
... a = 2
...
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 3, in Disallowed
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 87, in __setitem__
raise TypeError('Attempted to reuse key: %r' % key)
TypeError: Attempted to reuse key: 'a'
class Allowed(Enum):
... a = 1
... @property
... def a(self):
... return 2
...
Allowed.a
property object at 0x7f3d65da14d8
Allowed().a
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: __call__() missing 1 required positional argument: 'value'
Allowed(1).a
Traceback (most recent call last):
File stdin, line 1, in module
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 218, in __call__
return cls.__new__(cls, value)
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 439, in __new__
raise ValueError(%s is not a valid %s % (value, cls.__name__))
ValueError: 1 is not a valid Allowed
Allowed('a').a
Traceback (most recent call last):
File stdin, line 1, in module
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 218, in __call__
return cls.__new__(cls, value)
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 439, in __new__
raise ValueError(%s is not a valid %s % (value, cls.__name__))
ValueError: a is not a valid Allowed
Allowed['a'].a
Traceback (most recent call last):
File stdin, line 1, in module
File /home/ncoghlan/devel/py3k/Lib/enum.py, line 255, in __getitem__
return cls._member_map_[name]
KeyError: 'a'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 discoverable with tests. Let's please stop making enum more and more complex with all these needless type checks. We'll never get out of it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
Ethan Furman added the comment: In any other (normal) class, this works: == --class Okay: ... red = 1 ... green = 2 ... blue = 3 ... red = 4 == But not in Enum. And this works: == --class Color: ... red = 1 ... green = 2 ... blue = 3 ... def red(self): ... return 42 ... -- Color.red property object at 0x7fee4db306d8 == This only works in Enum because we added code to deal with it. If we hadn't, we'd see this: == Color.red: property object at 0x7fee4db30f58 == So right now the rule is: you can overwrite an enum member with anything besides another enum member. Considering the point of the Enum class is to create enum members this rule is nonsensical as it allows the removal of already created members. At the very least the rule should be: enum members cannot be overwritten. I prefer to have the rule: enum members cannot overwrite anything else, and cannot be overwritten by anything else. This seems to me to be a simpler, more consistent rule, and more in keeping with what an enumeration should be doing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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, in module
File stdin, line 5, in Color
File /home/ethan/source/python/issue18924/Lib/enum.py, line 87, in
__setitem__
raise TypeError('Attempted to reuse key: %r' % key)
TypeError: Attempted to reuse key: 'red'
==
versus
==
--class Color(Enum):
... red = 1
... green = 2
... blue = 3
... def red(self):
... return 'fooled ya!'
...
# no error
==
or
==
--class Color(Enum):
... red = 1
... green = 2
... blue = 3
... @property
... def red(self):
... return 'fooled ya!'
...
# no error
==
In both of the latter two cases the redefinition of 'red' is allowed because
the new definition is not an enum member.
This is inconsistent as well as confusing.
I know normal class creation semantics don't place any such limitations on
names and allow redefining at will, but Enum is not a regular class.
--
assignee: ethan.furman
files: no_reuse_of_enum_names.stoneleaf.01.patch
keywords: patch
messages: 197375
nosy: barry, eli.bendersky, eric.snow, ethan.furman, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: reuse of enum names in class creation inconsistent
type: behavior
versions: Python 3.4
Added file:
http://bugs.python.org/file31699/no_reuse_of_enum_names.stoneleaf.01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18989
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 rep...@bugs.python.org http://bugs.python.org/issue18989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18989] reuse of enum names in class creation inconsistent
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
