¿Por qué python max (‘a’, 5) devuelve el valor de la cadena?

Rastreando un ValueError: cannot convert float NaN to integer Descubrí que la línea:

 max('a', 5) max(5, 'a') 

devolverá a lugar de 5.

En el caso anterior, utilicé la cadena de ejemplo a pero en mi caso real, la cadena es un NaN (el resultado de un proceso de adaptación que no logró converger).

¿Cuál es la razón detrás de este comportamiento? ¿Por qué Python no reconoce automáticamente que hay una cadena allí y que debería devolver el número?

Aún más curioso es que min() funciona como se espera ya que:

 min('a', 5) min(5, 'a') 

devuelve 5 .

En Python 2, los valores numéricos siempre ordenan antes de las cadenas y casi todos los demás tipos:

 >>> sorted(['a', 5]) [5, 'a'] 

Los números entonces, se consideran más pequeños que las cadenas. Cuando se usa max() , eso significa que la cadena se selecciona sobre un número.

Que los números sean más pequeños es una elección de implementación arbitraria. Ver la documentación de las comparaciones :

Los operadores < , > , == , >= , <= y != Comparan los valores de dos objetos. Los objetos no necesitan tener el mismo tipo. Si ambos son números, se convierten a un tipo común. De lo contrario, los objetos de diferentes tipos siempre se comparan de forma desigual, y se ordenan de manera consistente pero arbitraria.

Énfasis en negrita el mio

Python 2 hizo todo lo posible para que los tipos heterogéneos se puedan clasificar, lo que ha causado muchos problemas difíciles de depurar, como los progtwigdores que intentan comparar enteros con cadenas y obtener resultados inesperados. Python 3 corrigió este error; obtendrá un TypeError lugar:

 >>> max(5, 'a') Traceback (most recent call last): File "", line 1, in  TypeError: unorderable types: str() > int() 

He escrito en otra parte sobre las reglas de pedido , e incluso he vuelto a implementar las reglas de Python 2 para Python 3 , si realmente querías recuperarlas.

En CPython 2.x, las cadenas siempre son mayores que los números, por eso ve esos comportamientos.

OTOH, no entiendo por qué crees que 5 es “obviamente” mayor que “a” … Los valores de diferentes tipos son comparables solo por conveniencia (por ejemplo, si estás construyendo un árbol RB con claves eterogéneas, quieres que todo sea comparables), y tales comparaciones sí definen un ordenamiento estricto y débil, pero las comparaciones entre tipos no pretenden ser sensatas de ninguna manera (¿cómo se compara un número con una cadena o un objeto?), simplemente coherente.