[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library

[Eli Bendersky]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130312/8749774c/attachment.html>