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

[R. David Murray]

On Mon, 25 Feb 2013 09:03:06 -0800, Eli Bendersky <eliben at gmail.com> wrote:
> 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 :-/

If we had labeled values, none of this would be a problem.  If you wanted
ints, you could use labeled ints as the values.  If you wanted strings,
labeled strings.  If you wanted incommensurate, unsortable objects,
you could use labeled objects as the values.

--David