<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently, if I want to store a list of homogeneous values I can use:<br>
<br>
  - list<br>
  - tuple<br>
  - bytes<br>
  - bytearray<br>
  - array.array<br>
<br>
Are these not "slightly different in subtle ways"?<br>
<br>
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.<br>


<br>
But, quite frankly, I see value in having different enumerations being different types, and in having NamedConstants...  perhaps some renaming would make things clearer?<br>
<br>
Currently:<br>
<br>
    EnumType<br>
<br>
    Enum(metaclass=EnumType)<br>
<br>
    BitMask(metaclass=EnumType)<br>
<br>
    Sequence(metaclass=EnumType)<br>
<br>
    String(metaclass=EnumType)<br>
<br>
<br>
Could be instead:<br>
<br>
    NamedConstantType<br>
<br>
    Enum(metaclass=<u></u>NamedConstantType)<br>
<br>
    NamedInt(int, metaclass=NamedConstantType)<br>
<br>
    NamedStr(str, metaclass=NamedConstantType)<br>
<br>
with available add-ons of BITMASK, INDEX, and ORDER.<br>
<br>
I don't know about you, but I like that a lot better.  :)<br></blockquote></div><br></div><div class="gmail_extra">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.<br>

<br>Eli<br><br><br><br></div><div class="gmail_extra"><br></div></div>