I just don't get it

[Eduardo Elgueta]

Hi All,

Would anyone be so kind to explain this?

-- begin --True
--end--

(Python2.3)

TIA.

Ed.

 

[Matt Gerrans]

Try comparing apples and apples:
False

 

[Stephen Horne]

Hi All,

Would anyone be so kind to explain this?

-- begin --
True
--end--

(Python2.3)

TIA.

Ed.

Those are different data types - you are comparing a tuple with a
number. When different data types are compared, Python uses an
arbitrary but consistent ordering. This can be very useful at times,
for example when maintaining and searching a sorted list.

If Python started trying to guess your intentions, and assumed that
you really meant to compare the values, a whole load of quite basic
things wouldn't work. Your example with different numbers may seem
obvious, but what if the numbers were the same? Which of the following
should return true?

(50,) < 50
(50,) == 50
(50,) > 50

If you think the middle one, what if the difference between having a
tuple and a number is important?

If you think that all should return false, you're not going to have
much luck with a lot of standard algorithms - it would violate a basic
assumption about ordering relations.

Personally, I might have gone with 'it makes no sense to compare
different types so raise an exception'. Possibly. But probably not.
Pythons system works very well in practice.


In Python, if you want to compare the actual numbers you need to
compare the actual numbers. It works out better in the long run when
your language isn't always second guessing what it thinks you really
meant.

 

[John Hazen]

Hi All,

Would anyone be so kind to explain this?

-- begin --
True
--end--

Comparing objects of different types (tuple and integer in your
example), while deterministic within a specific python version, puts
them in an arbitrary order.

() > 300 True
() > [] True
[] > () False
'a' > 300 True
'a' > () False
() > 'a' > 300 True
[] > 'a' False
[] > 300 True
() > 'a' > [] > 300

True


So, you probably don't want to be comparing disparate types and
attaching any meaning to the result.

If you wanted to compare the two numbers in your example, you would want
to index the tuple to get at the value inside it:

(176L,) > 300 True
(176L,)[0] > 300

False


HTH-

John
< my_first_name AT my_last_name DOT net >

 

[Stephen Horne]

If Python started trying to guess your intentions, and assumed that
you really meant to compare the values, a whole load of quite basic
things wouldn't work.

Just thought I'd chuck in a different example of what could happen if
Python started second guessing intentions.

(1,) == 1 .......... the numbers are both 1, after all

(1,) == () ......... maybe you're just checking they're both
tuples, after all?

But then for both those to be true, you also get...

1 == () ............ because 1 == (1,) == ()
2 == () ............ because 2 == (2,) == () by the same logic

1 == 2 ............. because 1 == () == 2


In short, you either have to live with inconsistencies in ordering
relationships that break standard algorithms and lead to all kinds of
unexpected problems in any program over about 100 lines of code, or
you have the ultimate egalitarian society of objects where every
object is equal to every other object, irrespective of value or
anything else.

Neither seems attractive to me.

 

[Eduardo Elgueta]

Stephen and everyone else,

Thank you very much for your answers. I'm not new to Python, but I
still have a long way to go

Ed.