[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
R. David Murray
rdmurray at bitdance.com
Fri Apr 12 17:23:19 CEST 2013
On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw <barry at python.org> wrote:
> Nick brought this up in private email, and my response was basically that
> iteration order for Enums should not be guaranteed, even if that happens to
> work in the current implementation. The reason why it works in the current
> implementation is purely to provide predictable reprs.
> Of course, we could sort the values for the repr and remove the sorted() call
> in EnumMetaclass.__iter__() but then we would have to add it back for
> IntEnums, since we *do* want to make explicit iteration order guarantees for
> IntEnums, as they also have full rich comparisons. I'm just not sure it's
> worth it from an implementation point of view.
> I will update the PEP to make this more clear.
> >In talking to an existing internet protocol it would be natural to use
> >IntEnum and this issue would not arise, but I have recently worked on
> >an application that had *exactly* the above sort of enumeration used
> >internally, when it would have been totally appropriate to use Enum rather
> >than IntEnum. The ap has several places where an ordered comparison
> >against the enum is used to check if a code is in the error range or not.
> Why Enums and not IntEnums? Enums will not have ordered comparisons, but
> IntEnums will.
To take advantage of their incommensurability with other Enums. It's
not a big deal, though; I'm more concerned that the API be internally
consistent. I presume that one could always define an Enum subclass
and provide comparison methods if desired :)
More information about the Python-Dev