A suspected bug

[Tim Peters]

[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.

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.

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