Guido van Rossum <guido@python.org> writes:
These could be two separate features. Named values could be a building block for a built-in Enum type -- the named value would take care of the str() and repr(), while the Enum type would only have to take care of the nice syntax ("class Color(Enum): red = 1; ...") and just create a bunch of named values in the class scope.
+1. As for EnumValue instances having a defined order, thanks to my reading of <URL:http://en.wikipedia.org/wiki/Enumerated_type> I can now say that some of us want an enumerated type that is not ordinal, and others want an ordinal type. And non-ordinal enumerated types, built-in, could then further be used as the basis for a custom ordinal type. Hence: * a built-in “named value” feature * a built-in, or standard-library, non-ordinal enumerated type feature (using the “named value” feature) * a standard-library ordinal type feature (using the enumerated type feature) Would that make us all happy? -- \ “We are stuck with technology when what we really want is just | `\ stuff that works.” —Douglas Adams | _o__) | Ben Finney