Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6817 > unrolled thread

Comparison operators in Python

Back to article view | Back to comp.lang.python

Contents

  Comparison operators in Python Anirudh Sivaraman <sk.anirudh@gmail.com> - 2011-06-01 11:50 -0700
    Re: Comparison operators in Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-06-01 22:08 +0300
    Re: Comparison operators in Python Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-01 13:16 -0600
      Re: Comparison operators in Python harrismh777 <harrismh777@charter.net> - 2011-06-01 19:44 -0500
        Re: Comparison operators in Python Terry Reedy <tjreedy@udel.edu> - 2011-06-02 02:09 -0400
        Re: Comparison operators in Python Michael Sparks <sparks.m@gmail.com> - 2011-06-02 03:05 -0700

#6817 — Comparison operators in Python

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

[toc] | [next] | [standalone]

#6818

Anirudh Sivaraman writes:

> 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.
>>> 3 < 'kolme'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()

[toc] | [prev] | [next] | [standalone]

#6819

On Wed, Jun 1, 2011 at 12:50 PM, Anirudh Sivaraman <sk.anirudh@gmail.com> wrote:
> 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.
>>> 'x' < 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() < int()

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#6829

Ian Kelly wrote:
>> 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:
>

    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.

[toc] | [prev] | [next] | [standalone]

#6842

On 6/1/2011 8:44 PM, harrismh777 wrote:
> Ian Kelly wrote:

 >> ?? wrote
>>> 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:

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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#6850

On Jun 2, 1:44 am, harrismh777 <harrismh...@charter.net> wrote:
..
>     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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web