I think the reason they are not supporting __lt__, __gt__,etc. is because ints are optional values for enums, therefore it wouldnt be a good idea to compare enums of different types in that way.
example: >>>class MyEnum(Enum): >>> fir = 1 >>> sec = 2 >>> thir = "THIRD!" and doing >>> MyEnum.fir >= MyEnum.thir would give unexpected results, therefore not making it a great idea On Fri, Apr 12, 2013 at 9:58 AM, R. David Murray <rdmur...@bitdance.com>wrote: > On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky <eli...@gmail.com> > wrote: > > Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also > pasted > > fully below for convenience]. > > This looks great. There's just one bit I don't understand. I'm sure > it was discussed in the python-ideas thread, but the discussion of it > in the PEP does not provide any motivation for the decision. > > > The ``Enum`` class supports iteration. Iteration is defined as the > > sorted order of the item values:: > > > > >>> class FiveColors(Enum): > > ... pink = 4 > > ... cyan = 5 > > ... green = 2 > > ... blue = 3 > > ... red = 1 > > >>> [v.name for v in FiveColors] > > ['red', 'green', 'blue', 'pink', 'cyan'] > > [...] > > > Ordered comparisons between enumeration values are *not* supported. > Enums > > are > > not integers (but see `IntEnum`_ below):: > > > > >>> Colors.red < Colors.blue > > Traceback (most recent call last): > > ... > > NotImplementedError > > >>> Colors.red <= Colors.blue > > Traceback (most recent call last): > > ... > > NotImplementedError > > >>> Colors.blue > Colors.green > > Traceback (most recent call last): > > ... > > NotImplementedError > > >>> Colors.blue >= Colors.green > > Traceback (most recent call last): > > ... > > NotImplementedError > > This is the part that I don't understand. Enums *clearly* have an > ordering, since the iteration order is defined and stable. Why should > I not be allowed to compare values from the same Enum type? There are > certainly use cases where that is very useful. > > To give you a concrete use case: consider response codes from a client > server application constructed the way typical internet protocols are. > We might have: > > class MyAppCode(Enum): > > ok = 200 > command_complete = 201 > status_response = 202 > help_response = 203 > service_ready = 204 > signoff_accepted = 205 > > temporary_failure = 400 > service_not_available = 401 > server_error = 402 > out_of_resources = 403 > > error = 500 > syntax_error = 501 > command_not_implemented = 502 > access_denied = 503 > resource_not_found = 504 > > > It can be quite handy to be able to say things like: > > code = myapp.operation(opstring) > if MyAppCode.temporary_failure < code < MyAppCode.error: > myframework.requeue(opstring, code=code) > return False > elif code > MyAppCode.error: > raise AppError(code) > .... > > 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. > > --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/sinistersnare%40gmail.com >
_______________________________________________ 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