[Python-ideas] PEP for enum library type?

[Greg Ewing]

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