On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <hrvoje.niksic@avl.com> wrote:The other day I was surprised to learn this:nan = float('nan') nan == nanFalse[nan] == [nan]True # also True in tuples, dicts, etc.That one surprises me a bit too: I knew we were using identity-then-equality checks for containment (nan in [nan]), but I hadn't realised identity-then-equality was also used for the item-by-item comparisons when comparing two lists. It's defensible, though: [nan] == [nan] should presumably produce the same result as {nan} == {nan}, and the latter is a test that's arguably based on containment (for sets s and t, s == t if each element of s is in t, and vice versa). I don't think any of this should change. It seems to me that we've currently got something approaching the best approximation to consistency and sanity achievable, given the fundamental incompatibility of (1) nan breaking reflexivity of equality and (2) containment being based on equality. That incompatibility is bound to create inconsistencies somewhere along the line. Declaring that 'nan == nan' should be True seems attractive in theory, but I agree that it doesn't really seem like a realistic option in terms of backwards compatibility and compatibility with other mainstream languages.
Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length.
If not equal, the sequences are ordered the same as their first differing elements. For example, [1,2,x] <= [1,2,y] has the same value as x <= y. If the corresponding element does not exist, the shorter sequence is ordered first (for example, [1,2] < [1,2,3]).