[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)
R. David Murray rdmurray at bitdance.com
Sat Apr 20 20:26:30 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 Sat, 20 Apr 2013 14:10:32 -0400, Barry Warsaw <barry at python.org> wrote:
On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>Just using definition order as the stable iteration order would do the >trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can >then override it. I think this isn't possible if we want to keep backward compatibility with earlier Pythons, which I want to do. OTOH, we have another natural sorting order for base Enums sitting right in front of us: the attribute name. These have to be unique and ordered, so why not use this for both the repr() and the base Enum iter()? IntEnum can override iter() to iterate over item values, which also must be ordered. I just made this change to flufl.enum and it seems to work well. >>> from flufl.enum import Enum >>> A = Enum('A', 'a b c') >>> A <A {a: 1, b: 2, c: 3}> >>> for item in A: print(item) ... A.a A.b A.c >>> B = Enum('B', 'c b a') >>> B <B {a: 3, b: 2, c: 1}> >>> for item in B: print(item) ... B.a B.b B.c >>> from flufl.enum import IntEnum >>> C = IntEnum('C', 'c b a') >>> C <C {a: 3, b: 2, c: 1}> >>> for item in C: print(item) ... C.c C.b C.a
I think definition order would be much better, but if we can't have that, this is probably better than value order for non-int.
--David
- 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 ]