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 type
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.
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?
1. 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)
4. 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! -- Greg