On 10/28/2012 7:18 PM, Chris Rebert wrote: > This is fixed in Python 3, where such nonsensical comparisons will > instead raise TypeError.
It's worth pointing out that at least one kind of inequality comparison which some people (e.g. me) would consider nonsensical is still allowed in Python 3, which is between Boolean values and numbers: >>> True < 1 False >>> False < 1 True which is probably because >>> True == 1 True >>> False == 0 True Many people (probably most people, to be honest) disagree with me that this is wrong, but regardless of whether you like it or not you need to know what happens in such cases. On 10/28/2012 7:18 PM, Chris Angelico wrote: > Which means that strings will ALWAYS be compared as strings, and > numbers will ALWAYS be compared as numbers, and ne'er the twain shall > conflict. I can trust Python to compare MD5 hashes reliably: > >>>> "912128034267498495410681495015e0" !=00912128034267498495410681495015" > True > > Of course, I'm not pointing fingers at any other languages here, but > this is a known security hole in one rather widely-used one. If you are PerHaPs talking about the language I think you are, my favorite fact about that is I'm that I think a while back I saw a bug entry about something like that and they weren't sure how or even if it should be fixed. Evan -- http://mail.python.org/mailman/listinfo/python-list
