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