Should I apply this?  There are more places that reference __cmp__ in
the library.  OTOH there are some folks who would like to see __cmp__
make a come-back as a shorthand for defining 6 comparison operators, for
totally-ordered types.  (I'm still waiting for a PEP describing this
though.)  Even in that case I'm not sure that the code I'm proposing to
delete here would be useful.

__cmp__ is not coming back.

Bumping priority.

Ping

Can someone other than me test and apply this?  It seems still relevant,
and __cmp__ is not coming back.

Additionally, there are still lots of references to __cmp__ in the
library which should be ripped out.

Bumping priority even further. This shouldn't make it past rc.

Guido's patch breaks these tests:

test_descr test_hash test_long test_richcmp test_set

Since we are making 3.0 issues deferred blockers dropping the priority.

> Guido's patch breaks these tests:
> 
> test_descr test_hash test_long test_richcmp test_set

It looks like all these are easily fixed:  all these tests were making 
outdated assumptions and needed updating.

Here's a patch that fixes these tests.

One other detail:

In test_descr.py, there are tests for 'overridden behavior for static 
classes' and 'overridden behavior for dynamic classes', using test classes 
'Proxy' and 'DProxy';  apart from the name change, the 'dynamic' code is 
identical to the 'static' code, so I removed it.  I guess this had to do 
with the __dynamic__ class attribute, which is ancient history, no?

Thanks, Mark! Applied in r66920.

The library still has __cmp__ functions defined here and there, e.g. in
xmlrpc/client.py.

Presumably any nonzero entries for tp_compare in type initializers 
should be looked at closely, as well?

I see nonzero tp_compare entries in:
  Modules/_tkinter.c
  Modules/parsermodule.c
  Objects/cellobject.c
  Objects/descrobject.c
  PC/winreg.c
  Objects/setobject.c
(but that last one just raises an error pointing out that cmp can't be 
used to compare sets, so maybe that's okay).

Let's lower the priority on this.

cmp() the function is also still there.

Bah. That means we'll have to start deprecating cmp() in 3.1, and won't
be able to remove it until 3.2 or 3.3. :-)

I hope the smiley really indicates a joke...

Well what would you suggest we do?

I'd release 3.0.1 quickly, maybe also with the in-development
improvements to the io library that alleviate the factor-1000 slowdowns.

Since cmp() was documented as removed in whatsnew3.0, it may be fair
game to complete the removal, treating it as a bugfix.  

If as Georg suggests it is done *very* quickly in 3.0.1 (say in the next
week or so), it is likely harmless and better than living with a
half-removed feature for the next three years.  Also, Georg intimated,
we will likely need to do 3.0.1 almost immediately anyway (the current
state of affairs with IO borders on the unusable.

A quick ballot on #python-dev resulted in 3 of 3 votes for removing
cmp() in a quick bug fix release.

About the io misery: 
My quick fix for the buffer reallocation schema has made the situation a
bit better. For the 3.0.x series I like to discuss if we shouldo declare
critical performance fixes as bug fixes and not as new features.

OK, remove it in 3.0.1, provided that's released this year.

Performance fixes are always fair game for bugfix releases.

Please don't "fix" the what's new document (or undo the fix).

I do hope cmp() was already undocumented elsewhere.

Do the API functions PyObject_Compare() and PyObject_Cmp() also go away?

Do we also get rid of the tp_compare type slot? 6 types still use it, 
they should convert this to a tp_richcompare slot

Yes, tp_compare should go.

tp_richcompare is less convenient to implement than tp_compare. See for 
example how in Objects/longobject.c, long_richcompare() calls long_compare() *and* a helper method Py_CmpToRich.

Likewise, turning __cmp__ into the whole set of __lt__, __le__, __ge__, 
__gt__, __eq__, __ne__ methods (did I forget one?) is tedious.

I'm not talking for my own code, but for the python standard objects and 
library (and the Demo directory) where I'm currently trying to remove 
__cmp__ and tp_compare.

I am not far to write a hack (mixin, metaclass) to inject rich 
comparison functions based on a single __cmp__ function.

Either take out the C-API functions or re-define them as:

   lambda a, b: (a > b) - (a < b)

r67627 : complete the dedocumenting of cmp().

Amaury, I have a non-metaclass solution for you.  Will post on ASPN.  It
uses a class decorator to sniff-out *any* defined rich ordering
comparisons and the automatically fills-in those that are missing.

FWIW, the tp_compare slot in setobject.c serves only say the cmp() isn't
defined.  It can be ripped-out straight-away.

+1 for a speedy removal of cmp and tp_compare

We shouldn't remove the tp_compae slot in 3.0. That's going to break too
much 3rd party software. Instead of removing it, a deprecation warning
should be printed when the slot isn't 0.

Here is a longer patch that removes cmp, PyObject_Compare and cmpfunc.
The slots has been renamed to tp_reserved. If the slot is used by a type
an exception is raised to notify the user about possible issues.

Missing:
* fix unit tests
* add error checks to PyObject_RichCompareBool calls
* Remove/replace the last PyUnicode Compare ASII function

I'll work on fixing the unit tests if that's helpful.

Can you fix the decimal module and tests? You know more about the module
than me. I'm half through most of the others modules.

Decimal fixes

I've integrated Mark's patch and fixed more tests. Who wants to pick it
up from here?

remove_cmp3.patch adds to Christian's patch to fix 6 more test_failures:
(test_distutils, test_kqueue, test_list, test_sort, test_sqlite, 
test_userlist).

On OS X, the only remaining test failure is test_unittest.py.

About unittest:

unittest.TestLoader has an attribute "sortTestMethodsUsing", which it 
expects to be an old-style comparison.

Should this attribute be updated (and renamed?) to expect a key function 
instead, or left as is?

On Sun, Dec 7, 2008 at 13:26, Mark Dickinson <report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> About unittest:
>
> unittest.TestLoader has an attribute "sortTestMethodsUsing", which it
> expects to be an old-style comparison.
>
> Should this attribute be updated (and renamed?) to expect a key function
> instead, or left as is?
>

It will break backwards-compatibility if you change it. Possibly the
best solution is to introduce a new attribute that does either key or
just lt comparison and make sortTestMethodsUsing be a descriptor that
wraps the function as needed.

The latest patch removes PyUnicode_Compare as well as lots of __cmp__
functions under Lib/. It also renames and redefines
PyUnicode_CompareWithASCIIString(). The simpler
PyUnicode_EqualToASCIIString() function is easier to use, too.

Update patch to include fix for unittest.py and test_unittest.py.

I've created a new branch to work on the issue:
svn+ssh://pythondev@svn.python.org/python/branches/py3k-issue1717. It's
easier to work on a branch than exchanging monster patches.

Please put the PyUnicode_Compare() API back in there.

Removing __cmp__ really doesn't have anything to do with removing often
used helper functions for comparing certain object types and only
cripples the C API in a needless way.

Thanks.

Instead of removing cmp(a, b) and replacing all uses with (a>b)-(b<a) I
think it's better to turn cmp() into a helper that applies this
operation in C rather than Python.

Marc-Andre, how  do you like a function PyUnicode_Equal() instead of
PyUnicode_Compare()?

The old PyUnicode_Compare() function returns -1 for smaller value and
errors, 0 for equality and +1 for larger value. I find it confusing to
have one function that follows the old PyObject_Compare() behavior.

Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0
for unequal and +1 for equal. The function follows the semantic of
http://docs.python.org/c-api/object.html#PyObject_RichCompareBool nicely.

About your proposal for cmp(), where should we put the method? I'm -0.5
on builtins.

IMO PyUnicode_Compare() should be replaced by a hypothetical
PyObject_RichCompare(), which allows to take shortcuts when comparing
strings of different length and a Py_EQ or Py_NE comparison is requested.
(see #3106 too)

On 2008-12-09 00:12, Christian Heimes wrote:
> Christian Heimes <lists@cheimes.de> added the comment:
> 
> Marc-Andre, how  do you like a function PyUnicode_Equal() instead of
> PyUnicode_Compare()?
> 
> The old PyUnicode_Compare() function returns -1 for smaller value and
> errors, 0 for equality and +1 for larger value. I find it confusing to
> have one function that follows the old PyObject_Compare() behavior.

For Unicode objects you don't have the issues with general rich
comparisons. Unicode objects only know <, = and >, so the C approach
of using -1, 0, +1 for these results will work just fine.

It doesn't in the general case, where comparisons can return arbitrary
objects.

> Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0
> for unequal and +1 for equal. The function follows the semantic of
> http://docs.python.org/c-api/object.html#PyObject_RichCompareBool nicely.

Yes, but for sorting Unicode (in C) and other quick checks that rely on
lexical ordering you need checks for < and > as well.

It's better to have just one C API than 3 or 5 to cover all comparison
cases.

> About your proposal for cmp(), where should we put the method? I'm -0.5
> on builtins.

Good question.

It is in the builtins in Python 2.x, so keeping it there would make
porting easier, but then it's probably better to put it somewhere else
to make people aware of the fact that the underlying machinery has
changed.

I wrote:
> IMO PyUnicode_Compare() should be replaced by a hypothetical
> PyObject_RichCompare(), which allows to take shortcuts when comparing
> strings of different length and a Py_EQ or Py_NE comparison is requested.

... and I didn't even remember that PyUnicode_RichCompare() already
exists. So let my proposal be to enable those optimizations inside the
existing PyUnicode_RichCompare(), and dump PyUnicode_Compare().

On 2008-12-09 00:58, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> I wrote:
>> IMO PyUnicode_Compare() should be replaced by a hypothetical
>> PyObject_RichCompare(), which allows to take shortcuts when comparing
>> strings of different length and a Py_EQ or Py_NE comparison is requested.
> 
> ... and I didn't even remember that PyUnicode_RichCompare() already
> exists. So let my proposal be to enable those optimizations inside the
> existing PyUnicode_RichCompare(), and dump PyUnicode_Compare().

What for ? What does this have to do with removing __cmp__ ?
Why do you want to break the C API for no apparent reason ?

I've designed the Unicode C API to be a rich API and would like
it to stay that way.

> It is in the builtins in Python 2.x, so keeping it there would make
> porting easier, but then it's probably better to put it somewhere else
> to make people aware of the fact that the underlying machinery has
> changed.

from __past__ import cmp

?

More seriously, if cmp were to go into the standard library somewhere,
perhaps Raymond's class decorator (for filling in missing rich
comparisons) could go into the same place?

Moving cmp() somewhere other than builtins is not progress.  IMO, it
needs to die off and the concept of it needs to disappear completely. 
Code is better without it.  Three-way comparisons are PITA to use --
their only virtue is as an optimization in the few cases where one
three-way test is cheaper to compute than two two-way tests.

The goal for 3.0 was to have one way to do it and thereby simplify the
language.  Tucking it away in a module or writing a new decorator
defeats the purpose.  It simply should die and go away.

On 2008-12-09 10:59, Raymond Hettinger wrote:
> Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
> 
> Moving cmp() somewhere other than builtins is not progress.  IMO, it
> needs to die off and the concept of it needs to disappear completely. 
> Code is better without it.  Three-way comparisons are PITA to use --
> their only virtue is as an optimization in the few cases where one
> three-way test is cheaper to compute than two two-way tests.
> 
> The goal for 3.0 was to have one way to do it and thereby simplify the
> language.  Tucking it away in a module or writing a new decorator
> defeats the purpose.  It simply should die and go away.

The idea was to have one implementation of the work-around (a>b) - (b<a)
instead of 10 or so instances of this snippet in the Python stdlib
and probably a few hundred places in other code.

Indeed, the motivation is to have one obvious way to write this
work-around :-)

Note that cmp() doesn't make __cmp__ come back, but it does help
porting code that uses cmp().

Besides, cmp() is available builtin in 3.0, so it's too late to just
remove it anyway. We'd have to go through the usual deprecation
process.

> The idea was to have one implementation of the work-around (a>b) - (b<a)
> instead of 10 or so instances of this snippet in the Python stdlib
> and probably a few hundred places in other code.

But what use-case does it solve, except for making legacy code easier to
port to Py3k?

On 2008-12-09 16:06, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> The idea was to have one implementation of the work-around (a>b) - (b<a)
>> instead of 10 or so instances of this snippet in the Python stdlib
>> and probably a few hundred places in other code.
> 
> But what use-case does it solve, except for making legacy code easier to
> port to Py3k?

It implements the DRY principle.

Guido approved removing __builtin__.cmp() in 3.0.1.  It was supposed to
have been taken out but was forgotten.

With respect to the DRY principle, I disagree about its utility here. 
The code is so simple that it doesn't warrant cross-module
factorization.  It is a better goal to minimize dependencies.

Still to do:

pybench needs updating to remove a cmp reference;  since the changes 
required for pybench are a little bit more substantial than simple cmp 
replacement, I've broken this out into a separate issue:  issue 4704.

There are many uses of cmp still in the Demos directory.  How much do we 
care?

The documentation in Doc/extending/newtypes.rst needs updating.  I can 
have a go at this, but Georg would almost certainly do a better job.

Should Py_CmpToRich (in object.c) disappear?

It's currently used in longobject.c, but nowhere else as far as I can 
tell.  It shouldn't be too hard to update longobject.c to remove the use.

> It shouldn't be too hard to update longobject.c to remove the use.

I'll do that one.

> > It shouldn't be too hard to update longobject.c to remove the use.
> 
> I'll do that one.

Done in r67871, r67873.

Please remember to add back PyUnicode_Compare() if that hasn't already
been done.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2008-12-02: Released mxODBC.Connect 1.0.0      http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

Here's a patch (against py3k) generated from the current state of the 
py3k-issue1717 branch, for ease of review and testing.

The patch needs serious review;  it should be considered a first draft, 
and there are probably many more changes still to be made.  I don't 
think I can do much more for now without getting input from others.

Known places in the source tree where cmp/__cmp__ still lingers on:

Demos/<many>
Doc/extending/newtypes.rst
Misc/cheatsheet
Misc/python-mode.el
Misc/Vim/python.vim
Parser/spark.py   # (I don't know what this does.  Anyone?)
Tools/<various>   # (notably pynche and pybench)

Apart from the newtypes.rst, all of the above files are somewhat out of 
date in other ways.  In my opinion it's only the doc fixes that stop the 
patch from being complete enough.

Doc/extending/newtypes.rst

  I'll fix this one after the patch has landed.

Misc/cheatsheet

  This needs a general overhaul.

Misc/python-mode.el

  I think this should be removed from the distribution; it's maintained
externally.

Parser/spark.py   # (I don't know what this does.  Anyone?)

  This is used by asdl_c.py which generates Python-ast.c -- it should be
updated.

[Georg Brandl, on spark.py]
> This is used by asdl_c.py which generates Python-ast.c -- it should be
> updated.

The only issue here is a single comment, which reads:

#  GenericASTMatcher.  AST nodes must have "__getitem__" and "__cmp__"

Still, I'm reluctant to remove or alter the comment without
understanding why it was there in the first place.  If someone more
familiar with AST stuff can confirm that __cmp__ is definitely no
longer needed, I'll remove the mention of it from the comment.

> Misc/cheatsheet
>
>  This needs a general overhaul.

I'll open a separate issue for this, if that's okay with everyone.  
Presumably 3.0.1 doesn't need to wait for Misc/cheatsheet to be updated.

I'm wondering how to move forward with this issue.  Might it make sense to 
break the current monster patch into a series of more-easily reviewed 
patches?  I was thinking of something like:

 - patch 1 (Python code): remove all uses of cmp from std. lib. and tests
 - patch 2 (C code): remove all uses of tp_compare from Modules and 
Objects
 - patch 3 : rename tp_compare to tp_reserved in all Modules and Objects 
(should be a very simple patch, but touches a lot of files)
 - patch 4 : fix docs, and look for any other loose ends that need
   cleaning up.

Here's patch 1: remove uses of cmp from library and tests (and also from 
Tools/unicode/makeunicodedata.py).  It involves essentially no user-
visible changes.  (At least, assuming that users aren't trying to access 
e.g., UserString.__cmp__ directly.)

The patch is against py3k.  All tests pass on my machine with this patch 
applied.

Anyone interested in reviewing this?

Quick comments on your patch:
- two files have unwanted modifications on non-ASCII characters
(Lib/heapq.py and Lib/sqlite3/test/hooks.py)
- you haven't renamed "__cmp__" to "_cmp" in Lib/xmlrpc/client.py:
deliberate?
- in Lib/heapq.py, there's a "_cmp__" which should be "_cmp"

Thanks, Antoine.  Here's a new patch.

> - two files have unwanted modifications on non-ASCII characters
> (Lib/heapq.py and Lib/sqlite3/test/hooks.py)

Fixed, I think.  Could you double check?

> - you haven't renamed "__cmp__" to "_cmp" in Lib/xmlrpc/client.py:
> deliberate?

Not deliberate!  This __cmp__ should simply be removed, I think---the rich 
comparison methods are already present.

> - in Lib/heapq.py, there's a "_cmp__" which should be "_cmp"

Replaced "_cmp__" (which was in a comment) with "comparison".

> Fixed, I think.  Could you double check?

It's ok!

Stage 1 committed in r69025 (py3k) and r69026 (release30-maint).

Can anyone who uses tkinter give me some advice?  Does PyTclObject in 
_tkinter.c need to have its tp_richcompare method implemented?  And if so, 
how do I go about testing the implementation?  It seems that PyTclObjects 
aren't directly exposed to Python under 'import tkinter'.

I'll hold off on any more checkins until the 3.0.1 thread on python-dev 
has resolved itself.

Mark,

I'm not a very huge user of tkinter, but I can tell you it would be
tricky to try getting a PyTclObject. It needs to be exposed if you want
to test it without relying on Tcl, but, to me they are just a
"temporary" object that serves to indicate the caller that it needs to
be converted to something else since _tkinter itself wasn't able to do
it. For this reason I would actually prefer to them not be comparable.

Thanks, Guilherme.

> For this reason I would actually prefer to them not be comparable.

That's fine with me, so long as we can be sure that there's no existing 
code that depends on them being comparable.  I can't figure out whether 
there's any legitimate way that the tp_compare slot (which is currently 
implemented) of a PyTclObject could ever be called.

I'm not going to get more time to work on this before
the weekend, so if anyone else wants to take over please
feel free.

Still to do for stage 2:  cell objects and slot
wrapper objects need to have tp_richcompare
implemented, to replace the tp_compare slots that
are being removed.

For 3.0, are you going to keep tp_compare slot in existence and just
assert that it is NULL?  Then in 3.1, remove the slot entirely?

If I understand Christian's plan correctly, it was to:

(1) raise TypeError for non-NULL tp_compare, and
(2) rename tp_compare to tp_reserved (with type void *).

and both of these would happen with 3.0.1, so no difference between
3.0.1 and 3.1.0.

It seems to me that if tp_compare is actually going to be removed then
that should be done in 3.0.1;  else third-party stuff that works with
3.0.x will fail with 3.1, due to the various tp_* fields being out of sync.

It would be nice not to have tp_reserved hanging around for the duration
of 3.x.  (Similarly for nb_reserved.)

Instead of tp_reserved, the name should be tp_deprecated_compare.

There should be a python-dev discussion around when to actually remove
the slot:

  3.0.1 -- binary incompatibility between minor releases (BAD)
  3.1.0 -- uncomfortable for writers who have to add #ifdefs
  4.0.0 -- no pain, just wasted space
  3.1.5 -- just plain mean :-)

Actually, I would like to repurpose tp_compare as tp_bytes for the
__bytes__ method.

On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report@bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin@python.org> added the comment:
>
> Actually, I would like to repurpose tp_compare as tp_bytes for the
> __bytes__ method.

Repurposing would be extremely bad as that would mean it is possible
for people to actually compile code with a busted __bytes__
implementation.

On Thu, Jan 29, 2009 at 2:39 PM, Brett Cannon <report@bugs.python.org> wrote:
>
> Brett Cannon <brett@python.org> added the comment:
>
> On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report@bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin@python.org> added the comment:
>>
>> Actually, I would like to repurpose tp_compare as tp_bytes for the
>> __bytes__ method.
>
> Repurposing would be extremely bad as that would mean it is possible
> for people to actually compile code with a busted __bytes__
> implementation.

Wasn't there another case of an old slot being reused?

>> On Thu, Jan 29, 2009 at 07:30, Benjamin Peterson <report@bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <benjamin@python.org> added the comment:
>>>
>>> Actually, I would like to repurpose tp_compare as tp_bytes for the
>>> __bytes__ method.
>>
>> Repurposing would be extremely bad as that would mean it is possible
>> for people to actually compile code with a busted __bytes__
>> implementation.
>
> Wasn't there another case of an old slot being reused?

Not that I can remember, but I'm sure someone will correct me if I'm wrong.

Here's stage 2:  remove uses of tp_compare from Objects and Modules, and
replace uses of PyObject_Compare with PyObject_RichCompareBool.
PyObject_Compare, cmp and friends still haven't been removed at this
stage.

In detail:
  - for cell objects, method wrapper objects, PyTclObjects, and
    PyST_Objects (in the parser module), remove the defined tp_compare
    methods and implement tp_richcompare instead.
  - add tests for cell comparisons and PyST_Object comparisons;  
reenable
    tests for method wrapper comparisons.  There are no tests for the
    PyTclObject comparisons.
  - remove tp_compare method from sets (all it did was emit an error
    message about the nonsensicality of doing order comparisons on sets)
  - in Objects/rangeobject.c and ElementTree, replace uses of
    PyObject_Compare with PyObject_RichCompareBool

I haven't stared very closely but it looks ok.
("spanish armada" might be replaced with "spanish inquisition", though)

Thanks for the review, Antoine.

Stage 2 applied to py3k in r69181, merged to 3.0 in r69182.

cmp, PyObject_Cmp and PyObject_Compare removed in r69184 (py3k) and r69185 
(release30-maint).

There's still the rename of the tp_compare slot to deal with, and a fair 
amount of cleaning up and documentation fixing to do.

All relevant changes from the py3k-issue1717 branch have now been merged into the py3k 
branch (and from there into the 3.0 maintenance branch), in a series of revisions.  
Here they are, listed in py3k/release30-maint pairs:

r69188, r69189,
r69190, r69191,
r69192, r69193,
r69214, r69215,
r69218, r69221,
r69224, r69225.

The idea to raise TypeError on non-NULL tp_compare was abandoned after Martin pointed 
out that it would be a binary incompatible change _[1], but Nick Coghlan suggested a 
DeprecationWarning when tp_compare is non-NULL and tp_richcompare is NULL _[2], and 
remarked that the warning should also be implemented for Python 2.7 when run with the -
3 option.

Still to do before this can be closed:

 - fix up Doc/extending/newtypes.rst;  I think Georg has said he'll
   take care of this, so once everything else is done I'll just reassign
   this issue to him and let him get on with it.

 - add Nick Coghlan's suggested DeprecationWarning.

 - grep through the sources looking for tp_compare, __cmp__, cmpfunc,
   PyObject_Cmp, PyObject_Compare and cmp, and check all remaining
   references are legitimate.

 - update pybench;  there's a separate issue already open for this.
   (issue 4704), and it looks like Antoine and Marc-André are on the
   case.

 - anything else that I've forgotten.

Thanks everyone for your help so far, especially Christian for much of
the original code and Antoine for code and review.

[1] http://mail.python.org/pipermail/python-dev/2009-February/085797.html
[2] http://mail.python.org/pipermail/python-dev/2009-February/085809.html

Deprecation warning for types that implement tp_compare but not 
tp_richcompare added in r69431, r69432.

Just the doc fixes in Doc/extending/newtypes.rst left.  Assigning to Georg  
and reducing priority.

Removing cmp() breaks distutils. I get the following exception, for
example using the just released version 3.0.1:

Traceback (most recent call last):
  File "setup.py", line 318, in <module>
    classifiers = classifiers)
  File "c:\Python30\lib\distutils\core.py", line 149, in setup
    dist.run_commands()
  File "c:\Python30\lib\distutils\dist.py", line 942, in run_commands
    self.run_command(cmd)
  File "c:\Python30\lib\distutils\dist.py", line 962, in run_command
    cmd_obj.run()
  File "c:\Python30\lib\distutils\command\build.py", line 128, in run
    self.run_command(cmd_name)
  File "c:\Python30\lib\distutils\cmd.py", line 317, in run_command
    self.distribution.run_command(command)
  File "c:\Python30\lib\distutils\dist.py", line 962, in run_command
    cmd_obj.run()
  File "c:\Python30\lib\distutils\command\build_ext.py", line 306, in run
    force=self.force)
  File "c:\Python30\lib\distutils\ccompiler.py", line 1110, in new_compiler
    return klass(None, dry_run, force)
  File "c:\Python30\lib\distutils\cygwinccompiler.py", line 314, in __init__
    if self.gcc_version <= "2.91.57":
  File "c:\Python30\lib\distutils\version.py", line 64, in __le__
    c = self._cmp(other)
  File "c:\Python30\lib\distutils\version.py", line 341, in _cmp
    return cmp(self.version, other.version)
NameError: global name 'cmp' is not defined

Fixed in r69682.

Darn.  That's really very annoying.  Apologies for missing this one.

Thanks for the quick fix, Benjamin.

Documentation updated in r70863.

New changeset 64e004737837 by R David Murray in branch '3.3':
#18324: set_payload now correctly handles binary input.
http://hg.python.org/cpython/rev/64e004737837

Has there been any resolution regarding `sortTestMethodsUsing`? See https://bugs.python.org/msg77261

I spend a decent time and read the documentation thrice before realizing it received an old-style compare function. Brett's proposal for a new attribute seems like a sane way to do this without breaking backwards compatibility. Or will this continue using an old-style compare function for the foreseeable future?

> Has there been any resolution regarding `sortTestMethodsUsing`?

My suspicion is if the docs don't suggest there's something else then nothing has been changed.