On 22 February 2013 15:21, Alex Stewart email@example.com wrote:
On Friday, February 22, 2013 4:53:27 AM UTC-8, Joao S. O. Bueno wrote:
Again, I thinnkt hat my 2002 code that expected a (1) working when it got a (True) instead was a great, great thing. And I think that lots of places where magical strings today ("str.decode" errors argument, "compile" mode argument) should be lifted up to expect constants and still keep working if one pass them the strings "replace" or "eval".
Ok, first of all, nobody's suggesting that wouldn't work. I'm not talking about comparing enums with base types (which I have no problem working like this), I'm talking specifically about comparing enums directly with other enums from a different category.
Ok. I do agree with your argumentation. And in fact, my previous example of ----------
disk_io.IDDLE == "iddle"
network.IDDLE == "iddle"
disk_io.IDDLE == network.IDDLE
False ----- If the final behavior in some cases is this, no one will get harmed. We alread hav e NaN == Nan -> False and the language does not explode. :-)
So, indeed - values in distinct enums should compare differently, even if they compare equal to their underlying value.
(sorry for making you write the extensive e-mail)