On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw <ba...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com