[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[R. David Murray]

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.

OK.

> >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 :)

--David