comparing strings and ints

[Gordon McMillan]

Randall Hopper writes:
[vast snippery]
> 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
1
>>>

Certainly nothing in Doc/lib/built-in-funcs.html mentions any 
danger in comparing arbitrary objects, nor the discussion in 
2.1.5.2 ( 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.

- Gordon