[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)
Barry Warsaw barry at python.org
Fri Apr 12 16:30:05 CEST 2013
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
You also may not duplicate values in derived enumerations::
>>> class BadColors(Colors): ... yellow = 4 ... chartreuse = 2 # Oops! Traceback (most recent call last): ... ValueError: Conflicting enums with value '2': 'green' and 'chartreuse' Is there a convenient way to change this behavior, namely to indicate that conflicts are acceptable in a given Enum? While I like the idea of catching mistaken collisions, I've seen far too many C/C++ scenarios where multiple names map to the same value. This does raise questions, as it's unclear whether each name should get its own representation, or whether it's better to let DupEnum.name1 is DupEnum.name2 be True.
Currently there is not. This behavior is defined in the metaclass.
(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after the class declaration work today?)
Yes, but the repr/str of the alias will show the original value.
>>> from flufl.enum import Enum
>>> Colors = Enum('Colors', 'red green blue')
>>> Colors.black = Colors.blue
>>> Colors.black
<EnumValue: Colors.blue [value=3]>
>>> Colors.black is Colors.blue
True-Barry
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]