On Thursday, February 21, 2013 11:54:49 AM UTC-8, Joao S. O. Bueno wrote:
4. They should subclass INTs in way it  is possible to interact with low level
libraries already using C Enums (only aplicable to those that need an
int value) -
their use should be as transparent as True and False are today.

Ok, I can see that would be a desirable trait (and personally I'm with you on that one), though I'm not sure it really qualifies as "required" (there are potential uses for int-enums which would still be useful/valid even if it couldn't do that automatically), but I'll definitely add that to my "desirable" list..
 
>1. Enums should represent themselves (str/repr) by symbolic names, not as ints,
> etc.
I would say that, while not "required", as low level languages lack this,
the whole idea is simply not worth implementing  without this. This is the
real motivation - and NB. also for "Constants", not only "Enums".

Frankly, I think this one is so easy it's really not worth fussing about that much.  It's pretty much a given that any solution we come up with will have this functionality anyway..

>2. Enums from different groups should preferably not compare equal to each 
> other (even if they have the same associated int value).
I am not shure about this requirement. I agree about "valueless" Enums, but
as far as they have values associated, they should behave just like
their values. I did not hear of anyone injured  by " True == 1" in Python.

Well, it's explicitly not a requirement (that's why it's under "desirable" instead of "required").  Here's the question, though:  Do you believe if a solution was proposed which had this property it would be a bad thing?

Note that this isn't really exactly the same as the "True == 1" case.  In my opinion the argument in favor of this is along the lines of:

class FooOptions (Enum):
    YES = 1
    MAYBE = 2
    NO = 3

class BarOptions (Enum):
    NO = 1
    MAYBE = 2
    YES = 3
 
def foofunc(choice):
    if choice == FooOptions.YES:
        do_something()

Now what if somebody calls foofunc(BarOptions.NO)?

Admittedly, this is a somewhat exaggerated case, but I still think it would be better if in these sorts of cases FooOptions.YES != BarOptions.NO (if one explicitly did want to test if the values were the same (regardless of enum type) they could do something like "if int(choice) == FooOptions.YES" instead)

--Alex