comparing strings and ints
grant at nowhere.
Wed Apr 12 23:40:04 CEST 2000
Randall Hopper wrote:
> |Randall Hopper:
> |>Gordon McMillan:
> |> |Randall Hopper wrote:
> |> |> Fredrik Lundh:
> |> |> |
> |> |> | Objects of different types always compare unequal, and are
> |> |> | ordered consistently but arbitrarily.
> |> |>
> |> |> 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...
>I was of course referring to the behavior Gordon McMillan
>mentioned in the message I replied to. Namely, that sorting a
>list of objects of hetrogenous primitive types "groups" the
>instances of a particular type together (ints together, strings
>I'm taking Gordon's word that that's what it does. The
>documentation you cited simply said "arbitrary" ordering.
No, it said "_consistently_ but arbitrarily" [emph added].
That means that you don't which result you will get when a
string and an int are compared, but you know you will always
get the _same_ result. That is sufficient to gaurantee that
ints will clump together and strings will clump together in a
sorted list. You just don't know in what order the clumps are
going be ahead of time.
>Unless it's documented as official behavior, I would think that
>expecting it is probably not a safe bet.
Assuming the quote is correct, it looks like documented
behavior to me.
Grant Edwards grante Yow! Dehydrated EGGS are
at STREWN across ROULETTE
More information about the Python-list