On 21/02/2013 23:24, Greg Ewing wrote:
On 22/02/13 08:18, Alex Stewart wrote:
In non-Python code, typically enums have always been represented under the covers as ints, and therefore must be passed back and forth as numbers. The fact that they have an integer value, however, is purely an implementation artifact. It comes from the fact that C and some other languages don't have a rich enough type system to properly make enums their own distinct
I don't think that's true for all languages. For example, enums in Pascal are definitely distinct types from integers, yet the language explicitly assigns them ordinal values and defines an ordering for them. Wirth must have thought there was a benefit in doing that.
Not necessarily. With respect to the great man, he may not have given the matter as much thought, or considered (or been interested in) as many use cases as the contributors to this thread have.
It doesn't seem unreasonable, therefore, to define two different categories of enums: one that has no concept of "value" (for pure-Python), and one which does have associated values but all values have to be specified explicitly
That sounds reasonable. However, I'm wondering if there isn't a third case: where you don't care about the values, but you do want them to have a defined ordering?
The same thought occurred to me, although I could not think of a use case on the spot. But I think that there surely are such.
- Enum syntax should not be "too magic". (In particular, it's
pretty clear at this point that creating new enums as a side-effect of name lookups (even as convenient as it does make the syntax) is ultimately not gonna fly)
- It shouldn't be necessary to quote enum names when defining
them (since they won't be quoted when they're used)
Satisfying both of these constraints without new syntax seems to be pretty much impossible. That seems to be the main sticking point in these discussions.
I want to check: Is this a valid summary of things?
It looks pretty comprehensive to me!
Apart from the point about maybe wanting to order enums, I agree. I think Alex is right when he says you want to create singleton enums that don't equate to anything else. We don't think of RED, GREEN, BLUE as being identical with the ints 1,2,3, and so don't want our implementation of them to compare equal to those ints. Rob Cliffe