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

Barry Warsaw barry at python.org
Fri Apr 26 00:23:10 CEST 2013

On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:

>On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw <barry at python.org> wrote:
>> On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote:
>>>Iteration order matters a lot if you don't want people complaining about
>>>enums being broken:
>>>  class Days(enum.Enum):
>>>    Monday = 1
>>>    Tuesday = 2
>>>    Wednesday = 3
>>>    Thursday = 4
>>>    Friday = 5
>>>    Saturday = 6
>>>    Sunday = 7
>> Sorry, that's still not a complete use case.  I don't see why you'd depend
>> on iteration order over Days for any particular functionality.
>You mean other than printing the days of the week in order without
>needing to worry about the specific values assigned to them?

My point is, "days of the week" has a natural ordering, so why wouldn't you
use IntEnum for that?  Problem solved.

There's no natural ordering for things like colors or animals, so the values
don't matter.  I claim that neither does the repr or iteration order except
that the former should be *predictable* and it would be nice to define the
latter, but that's not actually necessary.  Undefined iteration order would be
just as fine for Enum.

>Using sort-by-name also introduces other weirdness, such as subclasses
>potentially inserting their values in the middle of inherited names,
>rather than appending to the end as one might reasonably expect.

I don't see how iteration order could affect how you'd write the derived class

>While using sort-by-name is better than not providing a consistent
>ordering at all, using definition order is substantially less
>surprising than sorting by key name, and PEP 3115 and
>collections.OrderedDict makes that easy to support in Python 3.x.
>The fact that this will make for a behavioural difference between the
>standard library and flufl.enum does *not* count as an argument for
>making the behaviour of the standard library version less intuitive
>(if that was a valid argument, the 3.3+ ipaddress module would look a
>*lot* more like it's ipaddr inspiration).

Maybe.  If they care about iteration order at all, then they will have to
special case their code for Python's < 3.3, which means they'll probably have
to explicitly sort it anyway for the foreseeable future.  I guess it'll be
moot in 10 years though. ;)

They probably don't care about iteration order, which I think will be the
common case (heck, iteration over the enum will be pretty rare *anyway*).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130425/e06cc822/attachment.pgp>

More information about the Python-Dev mailing list