How does Python 2 compare string and int? Why do lists compare as greater than numbers, and tuples greater...
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?
python types comparison python-2.x
add a comment |
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?
python types comparison python-2.x
20
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.
– abarnert
Oct 23 '13 at 21:59
add a comment |
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?
python types comparison python-2.x
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?
python types comparison python-2.x
python types comparison python-2.x
edited Jul 18 '18 at 19:40
ivan_pozdeev
18.7k84790
18.7k84790
asked Jul 17 '10 at 7:48
polygenelubricantspolygenelubricants
281k101503591
281k101503591
20
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.
– abarnert
Oct 23 '13 at 21:59
add a comment |
20
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.
– abarnert
Oct 23 '13 at 21:59
20
20
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.
– abarnert
Oct 23 '13 at 21:59
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.
– abarnert
Oct 23 '13 at 21:59
add a comment |
2 Answers
2
active
oldest
votes
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()
53
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 8:19
7
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
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
Fun fact :complex(1,0) > 'abc'
isFalse
butcomplex(1,0) > complex(0,0)
raises aTypeError
– Eric Duminil
Jan 22 '17 at 18:48
|
show 4 more comments
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.
2
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3270680%2fhow-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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()
53
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 8:19
7
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
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
Fun fact :complex(1,0) > 'abc'
isFalse
butcomplex(1,0) > complex(0,0)
raises aTypeError
– Eric Duminil
Jan 22 '17 at 18:48
|
show 4 more comments
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()
53
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 8:19
7
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
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
Fun fact :complex(1,0) > 'abc'
isFalse
butcomplex(1,0) > complex(0,0)
raises aTypeError
– Eric Duminil
Jan 22 '17 at 18:48
|
show 4 more comments
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()
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()
edited May 23 '17 at 11:33
Community♦
11
11
answered Jul 17 '10 at 7:54
Mark ByersMark Byers
584k12413421335
584k12413421335
53
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 8:19
7
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
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
Fun fact :complex(1,0) > 'abc'
isFalse
butcomplex(1,0) > complex(0,0)
raises aTypeError
– Eric Duminil
Jan 22 '17 at 18:48
|
show 4 more comments
53
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 8:19
7
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
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
Fun fact :complex(1,0) > 'abc'
isFalse
butcomplex(1,0) > complex(0,0)
raises aTypeError
– Eric Duminil
Jan 22 '17 at 18:48
53
53
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 8:19
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 8:19
7
7
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
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
4
4
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
@KarelBilek: bool is a numeric type. And True==1 so it's neither < nor >.
– abarnert
Oct 12 '13 at 7:41
2
2
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
Lexographic order of their type names? When would you ever want this to be a feature? Who would ever use that?
– Jack
Nov 14 '14 at 23:03
3
3
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
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
|
show 4 more comments
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.
2
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
add a comment |
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.
2
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
add a comment |
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.
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.
edited May 5 '12 at 12:24
jamylak
82.4k17175197
82.4k17175197
answered Jul 17 '10 at 7:51
Ignacio Vazquez-AbramsIgnacio Vazquez-Abrams
577k10110581158
577k10110581158
2
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
add a comment |
2
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
2
2
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
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
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '17 at 14:37
I just came across this answer and agree with Tony Suffolk. Objects are NOT ordered by the type name when dissimilar.
– Exelian
Jun 8 '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
@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
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3270680%2fhow-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
20
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.
– abarnert
Oct 23 '13 at 21:59