I had the surprise, while wanted to use str.__cmp__ as
the cmp argument to list.sort(), that it seems buggy
compared to unicode.__cmp__, and that these methods
seem implemented quite differently (they have a
different type):

$ python
Python 2.4.1 (#2, Aug 25 2005, 18:20:57)
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release
2006.0)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> unicode.__cmp__
<slot wrapper '__cmp__' of 'unicode' objects>
>>> str.__cmp__
<method-wrapper object at 0xb7a164ac>
>>> u'a'.__cmp__(u'b')
-1
>>> 'a'.__cmp__('b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'str' object has no attribute '__cmp__'
>>> unicode.__cmp__(u'a', u'b')
-1
>>> str.__cmp__('a', 'b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: expected 1 arguments, got 2


Am I missing something ?

Logged In: YES 
user_id=1188172

String comparison is done with rich compare methods, namely
__lt__, __le__, __gt__, __ge__ and __eq__, __ne__.

Why str.__cmp__ exists and 'a'.__cmp__ does not, I cannot say.

Logged In: YES 
user_id=133955

You are right, I also forgot there is a builtin cmp()
function that works like expected. Still str.__cmp__'s
behaviour is a bit puzzling to me...

Logged In: YES 
user_id=80475

In the absence of a defined __cmp__ method for string
objects, str.__cmp__ inherits type.__cmp__ which is used for
comparing types.  That is why you can sort a list of types:


>>> sorted([int, complex, float, str, dict, list, tuple])
[<type 'complex'>, <type 'dict'>, <type 'float'>, <type
'int'>, <type 'list'>, <type 'str'>, <type 'tuple'>]