[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
ethan at stoneleaf.us
Mon Feb 25 18:34:54 CET 2013
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.
More information about the Python-Dev