On Sun, Feb 3, 2013 at 3:53 PM, João Bernardo <jbvsmo@gmail.com> wrote:

Hi, about this enum/const thing, The use case I like more is a class where you know all the
instances and not just a sequence of names.
Particularly It would be nice to have custom attributes and methods besides the value and the name.

I have my own implementation with a basic api somewhat borrowed from flufl.enum (plus a lot of other stuff),
but with this kind of support: https://github.com/jbvsmo/makeobj

I couldn't find the best way to express enums with the current python syntax, so I also wrote a simple
regex-parsed language to fit objects with an arbitrary level of complexity. I think, enumeration per se

is not much more useful than just a bunch of integers... Having this kind of control IMO is.

Although Java is not a good example of anything, they have a similar feature. What do you people think?

Personally, I disagree with the "more features is better" approach. Features have a cost - they complicate the implementation which makes it fragile, harder to maintain and harder to understand. Even more importantly, they make *user* code harder to understand.

Therefore it's IMHO best to decide on a basic functionality that brings most of the benefits, and then think about how to make the implementation *simpler*. All I really want from an enum is what I have in C and lack in Python - a nice, minimally type-safe way to name special constants. Having this in hand, I want the simplest and cleanest syntax possible, not more features.

Tim's implementation strikes a good balance - the syntax is as minimal as can be in a library implementation, and it provides all the basic features well. It adds some more, possibly at the cost of complexity, which may or may not be good. This is why I think that a PEP weighing features for/against inclusion is a logical next step.

Eli