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