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

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