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

Eli Bendersky eliben at gmail.com
Mon Feb 25 18:03:06 CET 2013

On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Le Mon, 25 Feb 2013 10:44:33 -0600, Skip Montanaro <skip at pobox.com> a écrit : > > 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?

It doesn't mean anything, but so what? "DOG" > "CAT" doesn't mean much either, and yet it's legal in Python.

"DOG" > "CAT" invokes lexicographical comparison between two strings, a well-defined and sensical operations. It simply means that in a sorted list of strings, "CAT" will come before "DOG". This is different from an enumeration that attempts to (at least logically) restrict a value to a set of pre-defined entities.

That said, I'm slowly starting to realize that enums try to impose a bit of static typing on Python, which may be the cause for so much friction :-/

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130225/ff669fb7/attachment.html>

More information about the Python-Dev mailing list