I think the behavior of NaN in comparisons is more confusing: >>> sorted([1,nan,2]) [1, nan, 2] >>> sorted([2,nan,1]) [2, nan, 1] >>> sorted([2,None,1]) Traceback (most recent call last): File "<pyshell#28>", line 1, in <module> sorted([2,None,1]) TypeError: unorderable types: NoneType() < int()
At least the third case is clear that I shouldn't have done that. The way nan works, the results of sorting where one of the values is nan is unpredictable and useless. Yes, I know the rules about how NaN values behave in comparisons. Notwithstanding that, sorting could use a different comparison rule imposing a total ordering: -inf, ..., inf, nan as some other systems do. --- Bruce On Thu, Nov 13, 2008 at 10:55 AM, Tim Peters <[EMAIL PROTECTED]> wrote: > [M.-A. Lemburg] > > ... > > So far, I haven't heard a single argument for why not having None > > participate in an ordering scheme is a good strategy to use, except > > that it's pure. > > I've tracked down plenty of program logic errors that would have been > discovered more easily if comparing None to (mostly, but among others) > integers and strings had raised an exception instead of returning a > meaningless true/false result. Perhaps you haven't. For those who > have, the attraction to making comparisons with None refuse to return > nonsense silently is both obvious and visceral. > > > > IMHO, practicality beats purity in this special case. > > If hiding program logic errors is practical, sure ;-) > > there-is-no-behavior-no-matter-how-bizarre-someone-won't > come-to-rely-on-ly y'rs - tim > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/bruce%40leapyear.org >
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com