RetroSearch Browse

Mon Feb 25 18:34:54 CET 2013 · https://mail.python.org/pipermail/python-dev/2013-February/124307.html

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~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-February/124307.html below:

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