[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as (original) (raw)

Skip Montanaro skip at pobox.com
Mon Feb 25 17:44:33 CET 2013

Besides "we just don't need them int-based in these use-cases" what are the reasons for the strong desire to have them be valueless?

Not sure about other people, but piggybacking off C semantics, while convenient, reflects the limitations of the C implementation more than anything else. An enumeration, while you can count its items, doesn't imply that the elements of the enumeration are naturally ordered. If you force an underlying association with integers, you imply ordering where none naturally exists. Given this:

critters = enum(DOG, CAT, RACCOON)

what does it mean that DOG < CAT? Python 3 got rid of a lot of nonsense comparisons:

~% python2.7 Python 2.7.3+ (2.7:df57314b93d1, Feb 24 2013, 23:25:05) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information.

_1 < None_ False ~% python3.3 Python 3.3.0+ (3.3:aae2bb2e3195, Feb 24 2013, 23:15:28) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. _1 < None_ Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() < NoneType()

It's not clear to me that sneaking artificial ordering in the back door via enumerations is the correct thing to do.

Skip

More information about the Python-Dev mailing list