Currently, if I want to store a list of homogeneous values I can use:

- list
- tuple
- bytes
- bytearray
- array.array

Are these not "slightly different in subtle ways"?

If simple is what we want, then do away with the "an enum is not an int" idea, toss out the "Color.red != OtherColor.red", and suddenly my four classes are down to two (int vs str), or flufl.enum suddenly handles many many more cases than it did before.

But, quite frankly, I see value in having different enumerations being different types, and in having NamedConstants... perhaps some renaming would make things clearer?

Currently:

EnumType

Enum(metaclass=EnumType)

BitMask(metaclass=EnumType)

Sequence(metaclass=EnumType)

String(metaclass=EnumType)

Could be instead:

NamedConstantType

Enum(metaclass=NamedConstantType)

NamedInt(int, metaclass=NamedConstantType)

NamedStr(str, metaclass=NamedConstantType)

with available add-ons of BITMASK, INDEX, and ORDER.

I don't know about you, but I like that a lot better. :)

It is actually better, because it emphasizes that NamedInt is just that, not a kind of Enum. There's just one enum. Moreover, I'm not sure why strings need to be named (they name themselves just fine). And moreover+, Bitmask IMHO is completely unnecessary in Python. So if that leaves us with NamedInt / NamedFloat (in a similar vein to Nick's proposals) and Enum (with the semantics of PEP 435) I don't have major objections.

Eli