why (1, 2, 3) > [1, 2, 3] is true?
in [Python]
|
From: fat bold cyclop on 25 Feb 2010 09:03 > Both are not equal, so the comparison returns an arbitrary result in Py2. Thanks, Stefan. If I understand you correctly the comparison is not valid. But I wonder if there is any logic behind this (in 2.x). Is it possible to predict result of this comparison? Thanks again, fbc
From: Richard Thomas on 25 Feb 2010 09:21 On Feb 25, 2:03 pm, fat bold cyclop <fat.bold.cyc...(a)gmail.com> wrote: > > Both are not equal, so the comparison returns an arbitrary result in Py2. > > Thanks, Stefan. If I understand you correctly the comparison is not > valid. > But I wonder if there is any logic behind this (in 2.x). > Is it possible to predict result of this comparison? > > Thanks again, > fbc I believe in 2.x they are ordered by the names of their types but I could be wrong. 1 < [] < '' < () < u''
From: Iain King on 25 Feb 2010 09:22 On Feb 25, 2:03 pm, fat bold cyclop <fat.bold.cyc...(a)gmail.com> wrote: > > Both are not equal, so the comparison returns an arbitrary result in Py2. > > Thanks, Stefan. If I understand you correctly the comparison is not > valid. > But I wonder if there is any logic behind this (in 2.x). > Is it possible to predict result of this comparison? > > Thanks again, > fbc I haven't looked in the source to check (and I'm almost 100% certain that tuple > list is an implementation detail), but I have not found any pair of tuple and list in which the list is treated as the greater. Possibly related: type(tuple()) is > type(list()). Or, to let the interpreter tell you why (1,2,3) > [1,2,3]: >>> tuple > list True Iain
From: Stefan Behnel on 25 Feb 2010 09:54 fat bold cyclop, 25.02.2010 15:03: >> Both are not equal, so the comparison returns an arbitrary result in Py2. > Thanks, Stefan. If I understand you correctly the comparison is not > valid. > But I wonder if there is any logic behind this (in 2.x). > Is it possible to predict result of this comparison? The result is predictable, it's just arbitrary in that it does not depend on the values that you are comparing but only on their type. Stefan
From: Terry Reedy on 25 Feb 2010 13:27 On 2/25/2010 9:21 AM, Richard Thomas wrote: > On Feb 25, 2:03 pm, fat bold cyclop<fat.bold.cyc...(a)gmail.com> wrote: >>> Both are not equal, so the comparison returns an arbitrary result in Py2. >> >> Thanks, Stefan. If I understand you correctly the comparison is not >> valid. >> But I wonder if there is any logic behind this (in 2.x). >> Is it possible to predict result of this comparison? In general, no. The result is arbitrary, with the constraint of being consistent within a particular run. >> Thanks again, >> fbc > > I believe in 2.x they are ordered by the names of their types but I > could be wrong. This is currently true in *CPython* 2.x, but that is an implementation artifact that has changed and might be different with other implementations. Terry Jan Reedy
|
Next
|
Last
Pages: 1 2 Prev: why (1, 2, 3) > [1, 2, 3] is true? Next: CGI File Upload Problem with Python 3.1 on IIS 7 |