comparing strings and ints
gmcm at hypernet.com
Wed Apr 12 18:30:23 CEST 2000
Randall Hopper writes:
> 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 together, etc.).
Back to the original subject: should comparing unlike types
throw an exception.
The argument for seems to be that comparing unlike types is
*probably* a programmer mistake. Certainly sometimes it is a
programmer mistake (else this thread would not exist). Other
times it is not. (I know I have made use of this behavior,
though I think only in ad-hoc interpreter usage.)
I find myself aware that all Python objects (implicit in Python,
but explicit in implementation) have a common root (in C,
PyObject). In that sense, it's perfectly natural to be able to
compare arbitrary objects safely.
In fact, current behavior already relies on "types" (eg,
"Number") that are not explicit:
>>> .9 < 1 < 1.1
Certainly nothing in Doc/lib/built-in-funcs.html mentions any
danger in comparing arbitrary objects, nor the discussion in
184.108.40.206 ( Lib | Built-in Types | Mutable Sequence Types | sort).
Personally, I read Doc/ref/comparisons.html as warning that
the ordering of types may change, not that comparing different
types might become illegal.
So, I'd think it is safe to rely on the types being ordered; even
if it is not safe to rely on the ordering.
More information about the Python-list