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

[Skip Montanaro]

> 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 "<stdin>", line 1, in <module>
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