Home Original page

comparing strings and ints

Fredrik Lundh effbot at telia.com
Wed Apr 12 10:08:15 EDT 2000 
Randall Hopper <aa8vb at yahoo.com> wrote
> Gordon McMillan:
>  |Randall Hopper wrote:
>  |> Fredrik Lundh:
>  |>  |
>  |>  |    Objects of different types always compare unequal, and are
>  |>  |    ordered consistently but arbitrarily.
>  |>
>  |> I can see 45 == '45' being false, and 45 != '45' being true.  But it
seems
>  |> to me that not throwing an exception for attempts at an ordered
comparison
>  |> with logical ordering operators (<, <=, etc.) on objects of different
>  |> primitive types (e.g. 45 < '45', 45 > '45') only lets bugs pass
through.
>  |>
>  |> Is there a case where this could be useful (with its undefined
behavior)?
>  |> I believe that is the root of the question.
>  |
>  |I'd happily bet your wife and firstborn child that there's code that
>  |relies on it <wink>, if only because after sorting a list, all the ints
>  |will end up in a clump, and all the strings in another, etc.
>
>
> Oh, I also have __no doubt__ that someone is using this unofficial,
> undocumented behavior.  But they don't have a leg to stand on if the
> ordering breaks in a future Python version ;-)

interestingly enough, you included my documentation quote in
a post claiming that this is an undocumented feature...

(if you want more background on *why* this design was chosen,
consider that python has a single comparision primitive __cmp__,
and that until a few versions ago, the interpreter happily ignored
exceptions raised by that primitive.  for more info on this topic,
search the site/newsgroup for "rich comparisions").

</F>

<!-- (the eff-bot guide to) the standard python library:
http://www.pythonware.com/people/fredrik/librarybook.htm
-->
More information about the Python-list mailing list