OK. Some code review comments:

- Please clean up the comment in classobject.c starting with "Method
objects are used for one purposes:" -- to begin with, "one purposes" is
ungrammatical.  Best to remove the (a) bullet and rephrase the whole
thing more like "Method objects are used for bound instance methods (...)"

- The error "unbound methods are not supported" sounds a bit strange;
better rephrase more positive as "self must not be None"

- There is still a comment left "No, it is an unbound method". Is this
code still reachable? I though all ways to set im_self to NULL/None are
blocked?

- Is bug 1202533 still worth testing for in test_descr.py?  I don't know
that using a lambda reproduces the error condition that once existed.


Functional suggestions:

- Do we really need im_class for anything any more?  ISTM that the one
place where it is still used (in method_repr), we could as well use the
class of im_self.  (And before you think of super() as a
counter-argument: super() passes the object's class in rather than the
class where the method is found (though this may be considered a bug).

- I think that, like func_code -> __code__, the im_xxx attributes should
be renamed __xxx__.

The 'new' module claims to exist solely for backwards compatibility.  If
that's true, why are we adding to it?  In any case, the
_BoundCFunction() class is redundant -- you can just use the "method"
type, which is easily accessed as any bound method's __class__
attribute.  And is there a use case for an *unbound* C function? If not,
you could replace boundcfunction() with just a call to the method type.