On 13 February 2013 14:25, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:

On Feb 11, 2013, at 5:28 AM, Eli Bendersky <eliben@gmail.com> wrote:

Can you elaborate on the utility of this feature? What realistic use cases do you see for it? I think that at this point it's important to weigh all benefits of features vs. implementation complexity, and there's absolutely no need to support every feature every other enum implementation has. I want to stress again that the most important characteristic of your implementation is the clean syntax which means that enums are so easy to define they don't really need special Python syntax and a library feature can do. However, there's a big leap from this to defining custom metaclasses for enums.

Well said.  I agree with you critique.
In the absence of compelling use cases,
the language is better-off without a complicated
new feature.

Absolutely. At the moment my implementation has everything in there as I've been incrementally finding syntactically cleaner ways of doing things. I intend to remove a lot of the extra functionality eventually - for example, supporting EnumMeta/EnumValue subclassing.

In any case, it looks like Guido is strongly heading towards flufl.enum - doesn't mean I won't keep working on my implementation, but it doesn't look like it will be the basis for a stdlib enum.

Tim Delaney