With the current Python equivalent `ClassMethod` implementation of `classmethod` given in Raymond Hettinger's _Descriptor HowTo Guide_, the following code snippet:

```
class A:
    @ClassMethod
    def f(cls, *, x): pass

print(A.f)
A.f(x=3)
```

prints:

> <function ClassMethod.\_\_get\_\_.<locals>.newfunc at 0x106b76268>

and raises:

> TypeError: newfunc() got an unexpected keyword argument 'x'

instead of only printing:

> <bound method A.f of <class '\_\_main\_\_.A'>>

like the `@classmethod` decorator would do.

So the `ClassMethod` implementation fails in two regards:
* it does not return a bound method to a class;
* it does not handle keyword-only arguments.

With this PR `ClassMethod` will correctly emulate `classmethod`. This approach (`types.MethodType`) is already used in the Python equivalent `Function` implementation of functions given earlier in the same guide.

This wasn't intended to be an exact equivalent. Instead, it focuses on the key action of classmethod which is prepending the class to the call.  Though less accurate, the current version communicates better.  I suggest adding a short comment to the effect that "newfunc" emulates "types.MethodType(self.f, klass)".

@Raymond Hettinger

> Though less accurate, the current version communicates better

I agree that types.MethodType is more accurate but may be less understandable. But in this case I think that the Function class for emulating instance methods should not use types.MethodType either, but a custom newfunc function as well. And **kwargs parameters should be added to both newfunc functions.

I'm going to close this because 1) I'm working on a somewhat major set of updates this guide already and 2) I think this tracker issue misses the point of what those guide is trying to do (communicating that the class is prepended to the argument stream but not trying to be a fully accurate drop in substitute).  The responsibility for describing in detail what @classmethod does belongs in libstdtypes.rst.  The goal in the descriptor how-to is to give an understanding of how descriptors work.

@Raymond Hettinger

> The goal in the descriptor how-to is to give an understanding of how descriptors work.

Okay. So I don't know if that was clear in my last message but that also means replacing the current "Function" implementation:

class Function(object):
    . . .
    def __get__(self, obj, objtype=None):
        "Simulate func_descr_get() in Objects/funcobject.c"
        if obj is None:
            return self
        return types.MethodType(self, obj)

with something like this:

class Function(object):
    . . .
    def __get__(self, obj, objtype=None):
        "Simulate func_descr_get() in Objects/funcobject.c"
        if obj is None:
            return self
        def newfunc(*args, **kwargs):
            return self(obj, *args, **kwargs)
        return newfunc
        # "newfunc" emulates "types.MethodType(self, obj)"

And as you said, adding a similar comment to the "ClassMethod" implementation (and **kwargs):

class ClassMethod(object):
    "Emulate PyClassMethod_Type() in Objects/funcobject.c"

    def __init__(self, f):
        self.f = f

    def __get__(self, obj, klass=None):
        if klass is None:
            klass = type(obj)
        def newfunc(*args, **kwargs):
            return self.f(klass, *args, **kwargs)
        return newfunc
        # "newfunc" emulates "types.MethodType(self.f, klass)"

How about taking another look at this after I've finished my more extensive rewrite based on my course materials.