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

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 :-/

-------------- 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