How does Python 2 compare string and int? Why do lists compare as greater than numbers, and tuples greater than lists?

Question

The following snippet is annotated with the output (as seen on ideone.com):

print "100" < "2"      # True
print "5" > "9"        # False

print "100" < 2        # False
print 100 < "2"        # True

print 5 > "9"          # False
print "5" > 9          # True

print [] > float('inf') # True
print () > []          # True

Can someone explain why the output is as such?

---

Implementation details

• Is this behavior mandated by the language spec, or is it up to implementors?
• Are there differences between any of the major Python implementations?
• Are there differences between versions of the Python language?

Agosto

Of the 3000 dups of this question, this one has an answer explaining why the language was designed this way (and why it was re-designed in 3.x). That isn't part of this question, but is part of many of the questions that get linked here. – Smalt

See also (not a duplicate): stackoverflow.com/questions/2214194 – Redvers

Answer 1

From the python 2 manual:

CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address.

When you order two strings or two numeric types the ordering is done in the expected way (lexicographic ordering for string, numeric ordering for integers).

When you order a numeric and a non-numeric type, the numeric type comes first.

>>> 5 < 'foo'
True
>>> 5 < (1, 2)
True
>>> 5 < {}
True
>>> 5 < [1, 2]
True

When you order two incompatible types where neither is numeric, they are ordered by the alphabetical order of their typenames:

>>> [1, 2] > 'foo'   # 'list' < 'str' 
False
>>> (1, 2) > 'foo'   # 'tuple' > 'str'
True

>>> class Foo(object): pass
>>> class Bar(object): pass
>>> Bar() < Foo()
True

One exception is old-style classes that always come before new-style classes.

>>> class Foo: pass           # old-style
>>> class Bar(object): pass   # new-style
>>> Bar() < Foo()
False

---

Is this behavior mandated by the language spec, or is it up to implementors?

There is no language specification. The language reference says:

Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily.

So it is an implementation detail.

Are there differences between any of the major Python implementations?

I can't answer this one because I have only used the official CPython implementation, but there are other implementations of Python such as PyPy.

Are there differences between versions of the Python language?

In Python 3.x the behaviour has been changed so that attempting to order an integer and a string will raise an error:

>>> '10' > 5
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    '10' > 5
TypeError: unorderable types: str() > int()

Peltz

That's good that they changed it in Py3k. When I first saw this question, my thoughts were 'what, this doesn't raise an error?'. – Alisealisen

N.B. An exception to the 2.x rule that different types are ordered by the name of the type is that the None object always compares as less than every other type. In 3.x comparing None with another type will still raise a TypeError. – Phlogistic

Hm. Why does both (True<1) and (True>1) returns False then? They are different types... – Eleph

@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >. – Smalt

Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that? – Crooked

@Jack, when you want something in a consistent order, like sorted(["hello",'343',34]) -- which works in python2.x and errors in 3.x – Vercelli

@Jack As the note said it's so that it works in a consistent (but arbitrary) order. It's not to be useful, but to avoid surprising you by changing the order. – Neurophysiology

For Python 2.7 following expression evaluates to True: None < False == 0 < {} < [] < '' – Ration

Fun fact : complex(1,0) > 'abc' is False but complex(1,0) > complex(0,0) raises a TypeError – Uriel

Wasn't there also a special case for None? – Redvers

Answer 2

Strings are compared lexicographically, and dissimilar types are compared by the name of their type ("int" < "string"). 3.x fixes the second point by making them non-comparable.

Amharic

But in python2 int's are less than dicts so it can't just be lexicographically by type name ? – Errecart

I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar. – Lifelong

@TonySuffolk66 numeric type is exception to that rule. NumericType is always lower than any other type (except of NoneType) in 2.7. – Expletive