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












164














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?










share|improve this question




















  • 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
















164














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?










share|improve this question




















  • 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














164












164








164


57





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?










share|improve this 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?







python types comparison python-2.x






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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












2 Answers
2






active

oldest

votes


















198














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()





share|improve this answer



















  • 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' is False but complex(1,0) > complex(0,0) raises a TypeError
    – Eric Duminil
    Jan 22 '17 at 18:48



















21














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.






share|improve this answer



















  • 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











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
});


}
});














draft saved

draft discarded


















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









198














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()





share|improve this answer



















  • 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' is False but complex(1,0) > complex(0,0) raises a TypeError
    – Eric Duminil
    Jan 22 '17 at 18:48
















198














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()





share|improve this answer



















  • 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' is False but complex(1,0) > complex(0,0) raises a TypeError
    – Eric Duminil
    Jan 22 '17 at 18:48














198












198








198






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()





share|improve this answer














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()






share|improve this answer














share|improve this answer



share|improve this answer








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' is False but complex(1,0) > complex(0,0) raises a TypeError
    – Eric Duminil
    Jan 22 '17 at 18:48














  • 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' is False but complex(1,0) > complex(0,0) raises a TypeError
    – 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













21














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.






share|improve this answer



















  • 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
















21














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.






share|improve this answer



















  • 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














21












21








21






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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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














  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Costa Masnaga

Fotorealismo

Sidney Franklin