l=[1,3,2]
l.sort(cmp=lambda x,y:y-x, key=lambda x: x)
print(l)

With CPython 2.7 this
1) could raise an exception like TypeError: conflicting arguments passed;
2) could ignore cmp= and print [1,2,3] on the basis that the new should override the old;
3) does ignore key= and prints [3,2,1] (why does not matter now),
but as near as I can tell, this is not documented.

Suggestion: in 5.6.4. Mutable Sequence Types, in footnote 8, after
"key specifies a function of one argument that is used to extract a comparison key from each list element: key=str.lower. The default value is None."
add "Ignored if *cmp* is also given."

On pydev, Mathew Woodcraft says the actual rule is
4) Neither 'wins': cmp is applied to the output of key.
which is consistent with my experiment also.

There's no need to guess what it does ;-)  We don't document by experiment when source and test suites are available.  

Mathew was correct, it works as documented:  the key function is applied  at the outset (as it always does) and then cmp function is used whenever a comparison is made (as it always does).  There is no special change in behavior when the two are used together; they are effectively orthogonal (the actual implementation is a bit more complicated).  IMO, the docs are correct as-is.

There is some question about whether to specifically elaborate on what happens when both are used together.  For the most part, users are better-off using either key-functions or cmp-functions but not both at the same time.  We may be doing them a disservice by suggesting otherwise.  

This has been out for several years now and no one has either noticed or cared, so I recommend closing with no change.

The 2.7 doc actually says that the two arguments to cmp are list items, rather than list items or keys "cmp specifies a custom comparison function of two arguments (list items)". And this "In general, the key and reverse conversion processes are much faster than specifying an equivalent cmp function." sort of suggests one or the other (but not both). That said, given the absence of overt problems, I agree with 
> We may be doing them a disservice by suggesting otherwise.

Thank you.