why (1, 2, 3) > [1, 2, 3] is true?

fat bold cyclop

unread,

Feb 25, 2010, 8:00:48 AM2/25/10

to

I tired to google for comparison of tuple to list but i failed.

Could anyone explain it to me?

Best regards,
fat bold cyclop

Stefan Behnel

unread,

Feb 25, 2010, 8:46:56 AM2/25/10

to pytho...@python.org

fat bold cyclop, 25.02.2010 14:00:

> I tired to google for comparison of tuple to list but i failed.
>
> Could anyone explain it to me?

Both are not equal, so the comparison returns an arbitrary result in Py2.

Note that this was fixed in Py3:

Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (1,2,3) > [1,2,3]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: tuple() > list()

Stefan

fat bold cyclop

unread,

Feb 25, 2010, 9:03:03 AM2/25/10

to

> 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

Richard Thomas

unread,

Feb 25, 2010, 9:21:56 AM2/25/10

to

I believe in 2.x they are ordered by the names of their types but I
could be wrong.

1 < [] < '' < () < u''

Iain King

unread,

Feb 25, 2010, 9:22:53 AM2/25/10

to

On Feb 25, 2:03 pm, fat bold cyclop <fat.bold.cyc...@gmail.com> wrote:

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

Stefan Behnel

unread,

Feb 25, 2010, 9:54:58 AM2/25/10

to pytho...@python.org

fat bold cyclop, 25.02.2010 15:03:

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

Terry Reedy

unread,

Feb 25, 2010, 1:27:11 PM2/25/10

to pytho...@python.org

On 2/25/2010 9:21 AM, Richard Thomas wrote:
> On Feb 25, 2:03 pm, fat bold cyclop<fat.bold.cyc...@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

r

unread,

Feb 25, 2010, 7:29:13 PM2/25/10

to

On Feb 25, 7:00 am, fat bold cyclop <fat.bold.cyc...@gmail.com> wrote:
> why (1, 2, 3) > [1, 2, 3] is true?

It's simple, Everything must have a value!

Robert Kern

unread,

Feb 25, 2010, 7:42:35 PM2/25/10

to pytho...@python.org

That is not at all an explanation, much less a true one. Please read the other
posts in this thread; they have explained the situation rather well.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco