Antoon Pardon wrote: > Op 2005-12-16, Ben Sizer schreef <[EMAIL PROTECTED]>: > > Is it possible to make it have the following sort of behaviour? : > > > >>>> ShirtSize.small == AppleSize.small > > True > >>>> ShirtSize.small is AppleSize.small > > False > > > > It works for comparing a boolean (True) vs. an integer (1), so it has > > some sort of precedent. (Especially if you make the tenuous assumption > > that True,False are language-supported 'enums' for 0 and 1.) > > I'm against it. I don't like the following returning True: > > ShirtSize.small in [ShirtSize.Medium, AppleSize.small]
I agree to an extent. I can see that being unwanted behaviour, although not really a big one, and no worse than in C++. I think that when you have a list of alternatives like that, they're either hard-coded by selectively picking from the enumeration's initialisation list, or by being generated according to some other criteria. Either way, it would be hard to end up with the wrong type of value into that list, I think. > I also think it may cause problems with other comparisons. > > Supose the following: > > col = Enum('red', 'green', 'blue') > paint = Enum('violet' , 'blue', 'red') > > Then we get the following situation: > > col.red == paint.red and col.blue == paint.blue > > but > > col.red < col.blue and paint.blue < paint.red I don't think that's a problem - does any other language make any guarantees on ordering across multiple enumerations? Transitivity within any single enumeration plus transivity of equivalence across multiple enumerations, should be enough for most needs, no? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list