182

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?
ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152
polygenelubricants
  • 376,812
  • 128
  • 561
  • 623
  • 26
    Of the 3000 dups of this question, [this one](http://stackoverflow.com/questions/2384078/why-is-0-true-in-python) 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. – abarnert Oct 23 '13 at 21:59
  • See also (not a duplicate): https://stackoverflow.com/questions/2214194/ – Karl Knechtel Jun 28 '22 at 21:32

2 Answers2

210

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()
xnx
  • 24,509
  • 11
  • 70
  • 109
Mark Byers
  • 811,555
  • 193
  • 1,581
  • 1,452
  • 59
    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?'. – JAL Jul 17 '10 at 08:19
  • 9
    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. – Dave Kirby Jul 17 '10 at 11:35
  • 1
    Hm. Why does both (True<1) and (True>1) returns False then? They are different types... – Karel Bílek Jul 24 '13 at 13:59
  • 5
    @KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >. – abarnert Oct 12 '13 at 07:41
  • 4
    Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that? – Jacklynn Nov 14 '14 at 23:03
  • 1
    @Jack, when you want something in a consistent order, like `sorted(["hello",'343',34])` -- which works in python2.x and errors in 3.x – gabe Jan 22 '15 at 15:25
  • @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. – SuperBiasedMan Dec 17 '15 at 16:12
  • For Python 2.7 following expression evaluates to True: `None < False == 0 < {} < [] < ''` – peterdemin Jan 21 '16 at 20:13
  • 4
    Fun fact : `complex(1,0) > 'abc'` is `False` but `complex(1,0) > complex(0,0)` raises a `TypeError` – Eric Duminil Jan 22 '17 at 18:48
  • Wasn't there also a special case for `None`? – Karl Knechtel Jan 28 '23 at 20:37
24

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.

jamylak
  • 128,818
  • 30
  • 231
  • 230
Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • 3
    But in python2 int's are less than dicts so it can't just be lexicographically by type name ? – Tony Suffolk 66 Apr 29 '17 at 20:11
  • 1
    I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar. – Exelian Jun 08 '17 at 14:37
  • @TonySuffolk66 numeric type is exception to that rule. NumericType is always lower than any other type (except of NoneType) in 2.7. – lef Oct 14 '17 at 21:35