Comparison operators in Python

[Anirudh Sivaraman]

Hi

I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?

Anirudh

 

[Jussi Piitulainen]

I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?

In Python 3 it is an error.

Python 3.1.1 (r311:74480, Feb 8 2010, 14:06:51)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()

 

[Ian Kelly]

Hi

I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?

It allows things like sorting of heterogeneous lists. It's generally
viewed as a wart, though, and it was fixed in Python 3:

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() < int()

Cheers,
Ian

 

[harrismh777]

It allows things like sorting of heterogeneous lists. It's generally
viewed as a wart, though, and it was fixed in Python 3:

Just another example (excluding print 1/2 and unicode) where 3.x
seems to be completely compatible with 2.x/ (tongue-in-cheek)


(do Brits say tongue-in-cheek?)





... just saying.

 

[Terry Reedy]

Ian Kelly wrote:

This was a Python 1.0 idea that Guido decided was more bug-inducing than
useful.

Just another example (excluding print 1/2 and unicode) where 3.x seems
to be completely compatible with 2.x/ (tongue-in-cheek)

Arbitrary comparisons were broken and effectively deprecated about a
decade ago with the introduction of the complex type. Just another
example where 3.x completes a process of change started years before.

 

[Michael Sparks]

    Just another example (excluding  print  1/2  and  unicode) where 3.x
seems to be completely compatible with 2.x/   (tongue-in-cheek)

One of the key purposes of the 3.x line of code is to get rid of warts
in the language. As a result, if someone is relying on warts, then
their code will break when changing from 2.x to 3.x.

IMO, this is actually a good thing since it encourages the reduction
in warty code. (People who want to use 2.x and 3.x can either use 2to3
and maintain 2to3-able code or write code that works in both 2.x and
3.x - which is eminently doable)

(do Brits say tongue-in-cheek?)

Yes.


Michael.