On 02/25/2013 08:44 AM, Skip Montanaro wrote:
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:
I certainly agree that there are some cases where an enumeration doesn't have any natural ordering; surely we can also
agree that there are some that do? This is why I think our new Enum should have a selectable underlying type: int,
bitmask (int is disguise ;), str, float -- whatever the developer needs. If ordering is not important, use str as your
backend, or we could even have a truly valueless backend for those occasions.
As far as not needing more than one type of enum: enumerations are used for counting and/or listing -- how many ways
can we count? int, float, complex, decimal, fraction; how many ways can we list? list, tuple, array.
I have no problem with having a valueless enum, or even with having it be the default -- so long as I can choose to use
a SequenceEnum (or IntEnum, whatever we call it) then I'll be happy.
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
