A suspected bug
Colin J. Williams
cjw at sympatico.ca
Sun Feb 18 12:50:31 EST 2001
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
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.
More information about the Python-list