Python 3.0 - is this true?

[Steve Holden]

Robin Becker wrote:
> Martin v. Löwis wrote:
>>> Sure:
>>>
>>> if len(L1) == len(L2):
>>>     return sorted(L1) == sorted(L2)  # check whether two lists contain
>>> the same elements
>>> else:
>>>     return False
>>>
>>> It doesn't really matter here what the result of the sorts actually is
>>> as long as the algorithm leads to the same result for all permutations
>>> on L1 ( and L2 ).
>>
>> Unfortunately, for many releases, the list's sort algorithm would not
>> provide that property. Release for release, new cases where found where
>> the builtin ordering was not transitive (i.e. you get a < b and b < c,
>> but not a < c). With funny definitions of __cmp__ in some classes, you
>> can still get this today.
> .......
> 
> In old style python there was a sort of standard behaviour whereby None
> was comparable with most of the other primitive types. That at least
> allowed us to performs various stupid tricks with data. Unfortunately it
> seems that None is no longer orderable even against itself.
> 
> Is there any advice on how to create N/A float or integer or string
> values? I assume the DB api will continue to return None for null
> columns no matter what the column type.
> 
> Presumably I can always define my own comparator which makes None < x
> for all x!=None.

Yes, you can (though that will mean subtyping the standard Python types
and ensuring you use only the subtypes, not always easy to maintain).

Of course, using SQL against a traditional RDBMS will not return rows
with NULL values for salary in a query such as

  SELECT name, address WHERE salary < 10000

precisely *because* NULL (absence of value) does not compare with any
value. So you could say that 3.0 is forcing us to acknowledge database
reality ;-)

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/