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/ -- http://mail.python.org/mailman/listinfo/python-list
