[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

Davis Silverman sinistersnare at gmail.com
Fri Apr 12 16:19:29 CEST 2013

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 <rdmurray at bitdance.com>wrote:

On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky <eliben at 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 commandcomplete = 201 statusresponse = 202 helpresponse = 203 serviceready = 204 signoffaccepted = 205 temporaryfailure = 400 servicenotavailable = 401 servererror = 402 outofresources = 403 error = 500 syntaxerror = 501 commandnotimplemented = 502 accessdenied = 503 resourcenotfound = 504

It can be quite handy to be able to say things like: code = myapp.operation(opstring) if MyAppCode.temporaryfailure < 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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/sinistersnare%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130412/d5196204/attachment.html>

More information about the Python-Dev mailing list