A suspected bug

[Colin J. Williams]

Tim points to a paragraph in the Language Reference.  I've added
the paragraph which follows it below.

Tim Peters wrote:

> [Colin J. Williams]
> > It seems to me that the bit of code below should report
> > a type inconsistency.
> > X-Mozilla-Status: 0009 Sep 20 2000, 12:29:43) [MSC 32 bit
> > (Intel)] on win32.
> > Portions Copyright 1994-2000 Mark Hammond (MarkH at ActiveState.com) - see
> > 'Help/About PythonWin' for further copyright information.
> > >>> print 2 > '1'
> > 0
> > >>> print 1 > '2'
> > 0
> > >>>
>
> It's functioning as designed and documented, so you may wish to argue that
> it's a design flaw, but it won't be considered "a bug".  As the Reference
> Manual says:
>
>     The operators <, >, ==, >=, <=, and != compare the values of
>     two objects.  The objects need not have the same type.  If both
>     are numbers, they are coverted to a common type.  Otherwise,
>     objects of different types always compare unequal, and are
>     ordered consistently but arbitrarily.
>
>> (This unusual definition of comparison was used to simplify the definition
>> of operations like sorting and the in and not in operators. In the future,
>> the comparison rules for objects of different types are likely to change.)
>
> The David Beazley book Python: Essential Reference has, on page 38:

"If the types differ, a coercion operation is performed to convert one
of the types to the other:"

This looks clear enough, but one has to delve into the list below to see
that a coercion is only performed in some cases.

>
>
> It so happens that objects of different non-numeric types are compared today
> by the string names of their types, so any integer compares less than any
> string today (because "int" < "string").
>
> I'd agree that's of marginal value, but that's the way it's always been, so
> it would break stuff if it changed.  For example, sometimes I have giant
> lists of objects of all kinds of types, and can reliably sort the list to
> bring all the objects of the same type next to each other.  It does have its
> charms.
>

Tim makes a case for maintaining cmp, to group objects of like type.
Perhaps consideration should be given to providing a new 'comp'
which behaves as cmp, but extends the range of coercible types.

>
> it-must-be-so-unpythonic-that-it's-pythonic-again-ly y'rs  - tim

Many thanks to Paul Foley and to all who responded.

Colin W.