Confronto tra nessuno con tipi predefiniti usando operatori aritmetici?

Question

Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on win32 
Type "help", "copyright", "credits" or "license" for more information. 
>>> None > 0 
False 
>>> None == 0 
False 
>>> None < 0 
True 

• è il confronto None utilizzando operatori aritmetici ben definiti per tipi predefiniti (interi in questo caso)?
• È la differenza tra le prime due e le terze parti di confronto delle specifiche del linguaggio (le specifiche di Python - si deve scherzare :)) o sono i dettagli di implementazione di CPython?

Answer 1

L'unico confronto significativo si può davvero utilizzare con None è if obj is None: (o if obj is not None:).

Il confronto tra diversi tipi è stato rimosso da Python 3 per buone ragioni: erano una fonte comune di errori e causa confusione. Per esempio

>>> "3" < 4 
False 

In Python 3, si ottiene un TypeError quando si confrontano i valori di tipo diverso, come str vs. int o niente contro None.

>>> None < 0 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
TypeError: unorderable types: NoneType() < int() 

(intendo "a confronto", nel senso di cercare di determinare quale dei due valori è maggiore/minore di confronto per l'uguaglianza è OK -. Sarà sempre tornare False se due oggetti sono di diversi tipi.)

non hanno trovato un punto di riferimento nella documentazione di questo, ma in Learning Python, 4th edition, Mark Lutz scrive a pagina 204:

[...] Comparisons of differently typed objects (e.g., a string and a list) work — the language defines a fixed ordering among different types, which is deterministic, if not aesthetically pleasing. That is, the ordering is based on the names of the types involved: all integers are less than all strings, for example, because "int" is less than "str" .

Answer 2

Alcune citazioni interessanti dal http://bytes.com/topic/python/answers/801701-why-none-0-a

In early Python, the decision was made that the comparison of any two objects was legal and would return a consistent result. So objects of different types will compare according to an ordering on their types (an implementation dependent, unspecified, but consistent ordering), and objects of the same type will be compared according to rules that make sense for that type.

Other implementations have the right to compare an integer and None differently, but on a specific implementation, the result will not change.

Python 3 will raise an exception on such comparisons.

e

The problem is the typical one; Python did not originally have a Boolean type, and the retrofit resulted in weird semantics. C has the same issue.