Tracing back a ValueError: cannot convert float NaN to integer
I found out that the line:
max('a', 5)
max(5, 'a')
will return a
instead of 5.
In the above case I used the example string a
but in my actual case the string is a NaN
(the result of a fitting process that failed to converge).
What is the rationale behind this behaviour? Why doesn't python recognize automatically that there's a string there and that it should return the number?
Even more curious is that min()
does work as expected since:
min('a', 5)
min(5, 'a')
returns 5
.
In Python 2, numeric values always sort before strings and almost all other types:
>>> sorted(['a', 5])
[5, 'a']
Numbers then, are considered smaller than strings. When using max()
, that means the string is picked over a number.
That numbers are smaller is an arbitrary implementation choice. See the Comparisons documentation:
The operators <
, >
, ==
, >=
, <=
, and !=
compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily.
Bold emphasis mine.
Python 2 tried real hard to make heterogenous types sortable, which has caused a lot of hard to debug problems, such as programmers trying to compare integers with strings and getting unexpected results. Python 3 corrected this mistake; you'll get a TypeError
instead:
>>> max(5, 'a')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() > int()
I've written elsewhere about the ordering rules, and even re-implemented the Python 2 rules for Python 3, if you really wanted those back.
In CPython 2.x strings are always greater than numbers, that's why you see those behaviors.
OTOH, I don't get why you think that 5 is "obviously" greater than "a"... Values of different types are comparable just for convenience (e.g. if you are building an RB tree with eterogeneous keys you want everything to be comparable), and such comparisons do define a strict weak ordering, but inter-type comparisons are not intended to be sensible in any way (how do you compare a number to a string or an object?), just coherent.