On Thursday, February 21, 2013 11:54:49 AM UTC-8, Joao S. O. Bueno wrote:<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">4. They should subclass INTs in way it  is possible to interact with low level
<br>libraries already using C Enums (only aplicable to those that need an
<br>int value) -
<br>their use should be as transparent as True and False are today.
<br></blockquote><div><br></div><div>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..</div><div> </div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>1. Enums should represent themselves (str/repr) by symbolic names, not as ints,
<br>> etc.
<br>I would say that, while not "required", as low level languages lack this,
<br>the whole idea is simply not worth implementing  without this. This is the
<br>real motivation - and NB. also for "Constants", not only "Enums".</blockquote><div><br></div><div>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..</div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>2. Enums from different groups should preferably not compare equal to each <br></blockquote><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> other (even if they have the same associated int value).
<br>I am not shure about this requirement. I agree about "valueless" Enums, but
<br>as far as they have values associated, they should behave just like
<br>their values. I did not hear of anyone injured  by " True == 1" in Python.</blockquote><div><br></div><div>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?</div><div><br></div><div>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:</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><font face="courier new, monospace">class FooOptions (Enum):</font></div><div><font face="courier new, monospace">    YES = 1</font></div><div><font face="courier new, monospace">    MAYBE = 2</font></div><div><font face="courier new, monospace">    NO = 3</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">class BarOptions (Enum):</font></div><div><font face="courier new, monospace">    NO = 1</font></div><div><font face="courier new, monospace">    MAYBE = 2</font></div><div><font face="courier new, monospace">    YES = 3</font></div><div><font face="courier new, monospace"> </font></div><div><font face="courier new, monospace">def foofunc(choice):</font></div><div><font face="courier new, monospace">    if choice == FooOptions.YES:</font></div><div><font face="courier new, monospace">        do_something()</font></div></blockquote><div><br></div><div>Now what if somebody calls foofunc(BarOptions.NO)?</div><div><br></div><div>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)</div><div><br></div><div>--Alex</div>