Title: classmethod doesn't honour descriptor protocol of wrapped callable
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: berker.peksag, daniel.urban, grahamd, gvanrossum, ionelmc, pitrou, rhettinger, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2013-09-22 13:22 by grahamd, last changed 2018-07-23 10:30 by berker.peksag.

File name Uploaded Description Edit
funcobject.c.diff grahamd, 2013-09-22 13:22 Patch to classmethod tp_descr_get to do descriptor binding on wrapped object.
issue19072.diff berker.peksag, 2016-05-05 17:51 review
Pull Requests
URL Status Linked Edit
PR 8405 open berker.peksag, 2018-07-23 10:30
Messages (15)
msg198274 - (view) Author: Graham Dumpleton (grahamd) Date: 2013-09-22 13:22
The classmethod decorator when applied to a function of a class, does not honour the descriptor binding protocol for whatever it wraps. This means it will fail when applied around a function which has a decorator already applied to it and where that decorator expects that the descriptor binding protocol is executed in order to properly bind the function to the class.

A decorator may want to do this where it is implemented so as to be able to determine automatically the context it is used in. That is, one magic decorator that can work around functions, instance methods, class methods and classes, thereby avoiding the need to have multiple distinct decorator implementations for the different use case.

So in the following example code:

class BoundWrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __call__(self, *args, **kwargs):
        print('BoundWrapper.__call__()', args, kwargs)
        print('__wrapped__.__self__', self.__wrapped__.__self__)
        return self.__wrapped__(*args, **kwargs)

class Wrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __get__(self, instance, owner):
        bound_function = self.__wrapped__.__get__(instance, owner)
        return BoundWrapper(bound_function)

def decorator(wrapped):
    return Wrapper(wrapped)

class Class(object):
    def function_im(self):
        print('Class.function_im()', self)

    def function_cm_inner(cls):
        print('Class.function_cm_inner()', cls)

    def function_cm_outer(cls):
        print('Class.function_cm_outer()', cls)

c = Class()


A failure is encountered of:

$ python3.3
BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x1029fc150>
Class.function_im() <__main__.Class object at 0x1029fc150>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

Traceback (most recent call last):
  File "", line 40, in <module>
TypeError: 'Wrapper' object is not callable

IOW, everything is fine when the decorator is applied around the classmethod, but when it is placed inside of the classmethod, a failure occurs because the decorator object is not callable.

One could argue that the error is easily avoided by adding a __call__() method to the Wrapper class, but that defeats the purpose of what is trying to be achieved in using this pattern. That is that one can within the bound wrapper after binding occurs, determine from the __self__ of the bound function, the fact that it was a class method. This can be inferred from the fact that __self__ is a class type.

If the classmethod decorator tp_descr_get implementation is changed so as to properly apply the descriptor binding protocol to the wrapped object, then what is being described is possible.

Having it honour the descriptor binding protocol also seems to make application of the Python object model more consistent.

A patch is attached which does exactly this.

The result for the above test after the patch is applied is:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x10ad237d0>
Class.function_im() <__main__.Class object at 0x10ad237d0>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

That is, the decorator whether it is inside or outside now sees things in the same way.

If one also tests for calling of the classmethod via the instance:


Everything again also works out how want it:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

FWIW, the shortcoming of classmethod not applying the descriptor binding protocol to the wrapped object, was found in writing a new object proxy and decorator library called 'wrapt'. This issue in the classmethod implementation is the one thing that has prevented wrapt having a system of writing decorators that can magically work out the context it is used in all the time. Would be nice to see it fixed. :-)

The wrapt library can be found at:

The limitation in the classmethod implementation is noted in the wrapt documentation at:
msg198672 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-09-30 03:27
I don't think it was ever intended that decorators be chained together.  

The whole point is to control binding behavior during dotted look-up (when __getattribute__ is called) and not in other circumstances (such as a direct lookup in a class dictionary).

Note that classmethods typically wrap regular functions which have both __call__ and __get__ methods.   The classmethod object intentionally invokes the former instead of the latter which would unhelpfully create an inner bound or unbound method.
msg198673 - (view) Author: Graham Dumpleton (grahamd) Date: 2013-09-30 03:43
The classmethod __get__() method does:

static PyObject *
cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
    classmethod *cm = (classmethod *)self;

    if (cm->cm_callable == NULL) {
                        "uninitialized classmethod object");
        return NULL;
    if (type == NULL)
        type = (PyObject *)(Py_TYPE(obj));
    return PyMethod_New(cm->cm_callable,
                        type, (PyObject *)(Py_TYPE(type)));

So it isn't intentionally calling __call__(). If it still doing binding, but doing it by calling PyMethod_New() rather than using __get__() on the wrapped function. Where it wraps a regular function the result is same as if __get__() was called as __get__() for a regular function internally calls PyMethod_New() in the same way.

static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
    if (obj == Py_None)
        obj = NULL;
    return PyMethod_New(func, obj, type);

By not using __get__(), you deny the ability to have chained decorators that want/need the knowledge of the fact that binding was being done. The result for stacking multiple decorators which use regular functions (closures) is exactly the same, but you open up other possibilities of smarter decorators.
msg198679 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-09-30 06:11
I'll take a look at this in more detail in the next week or so.
msg198682 - (view) Author: Graham Dumpleton (grahamd) Date: 2013-09-30 07:17
If you have the time, would be great if you can have a quick look at my wrapt package. That will give you an idea of where I am coming from in suggesting this change.

In short, aiming to be able to write decorators which are properly transparent and aware of the context they are used in, so we don't have this silly situation at the moment where it is necessary to write distinct decorators for regular functions and instance methods. A classmethod around another decorator was the one place things will not work as would like to see them work.

I even did a talk about writing better decorators at PyCon NZ. Slides with notes at:

msg201512 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-10-28 05:38
Antoine, do you have any thoughts on this proposal?
msg201523 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-10-28 10:50
Well... I've not written enough descriptor-implementing code to have a clear opinion on this, but this looks quite obscure. I have personally never needed anything like the wrapt library (I've also never used the PyPI "decorator" module, FWIW).
msg201572 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2013-10-28 19:25
@grahamd: I occasionally have felt the pain of wrapping @classmethod (or @staticmethod). Never enough though to think of how to fix it. I really don't have the stomach to review your wrapt library, but your code looks okay except for style and missing tests. I'd also recommend adding a few words to the docs. (And yes, all of this is your responsibility -- nobody has time to do all that stuff for you.)

- the continuation line in your patch is not properly formatted;
- either the else block should also use { } or the else clause should be omitted.
msg201713 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-10-30 06:31
Graham, do we have a contributor agreement from you?
msg201714 - (view) Author: Graham Dumpleton (grahamd) Date: 2013-10-30 06:36
I don't believe so.
msg264911 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-05-05 17:51
Here is an updated patch with a test (adapted from msg198274.)
msg264916 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-05-05 19:28
With the patch class properties work:

>>> class A:
...     @classmethod
...     @property
...     def __doc__(cls):
...         return 'A doc for %r' % cls.__name__
>>> A.__doc__
"A doc for 'A'"

This is worth to be explicitly documented.
msg321217 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-07-07 12:29
Berker, do you mind to create a PR?

Supporting class properties looks good rationale to me. But we need to check how this change affects performance.
msg321222 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-07-07 16:11
> Berker, do you mind to create a PR?

I will submit a PR tomorrow.

Do you have specific ideas for a micro-benchmark in mind or do you want to me just run the Python benchmark suite against the patch?
msg321227 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-07-07 18:03
I think it is impossible to get significant impact on the Python benchmark suite from this patch. But mickrobenchmarks can expose the regression if it exists. Something like:

    ./python -m perf timeit -s 'class A:' -s ' @classmethod' -s ' def cm(cls): pass' -- ''
    ./python -m perf timeit -s 'class A:' -s ' @classmethod' -s ' def cm(cls): pass' -s 'f =' -- 'f()'
Date User Action Args
2018-07-23 10:30:37berker.peksagsetpull_requests: + pull_request7931
2018-07-07 18:03:59serhiy.storchakasetmessages: + msg321227
2018-07-07 16:11:43berker.peksagsetmessages: + msg321222
2018-07-07 12:29:50serhiy.storchakasetversions: + Python 3.8, - Python 3.6
2018-07-07 12:29:41serhiy.storchakasetmessages: + msg321217
2016-05-05 19:28:39serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg264916
2016-05-05 17:51:59berker.peksagsetfiles: + issue19072.diff
versions: + Python 3.6, - Python 3.4
nosy: + berker.peksag

messages: + msg264911

stage: patch review
2016-01-13 10:38:41ionelmcsetnosy: + ionelmc
2013-10-30 06:36:21grahamdsetmessages: + msg201714
2013-10-30 06:31:48rhettingersetmessages: + msg201713
2013-10-28 19:25:40gvanrossumsetmessages: + msg201572
2013-10-28 10:50:08pitrousetnosy: + gvanrossum
messages: + msg201523
2013-10-28 05:38:54rhettingersetnosy: + pitrou
messages: + msg201512
2013-09-30 07:17:57grahamdsetmessages: + msg198682
2013-09-30 06:11:37rhettingersetmessages: + msg198679
2013-09-30 03:43:31grahamdsetmessages: + msg198673
2013-09-30 03:27:04rhettingersetmessages: + msg198672
2013-09-30 03:19:32rhettingersetassignee: rhettinger

nosy: + rhettinger
2013-09-29 10:13:38daniel.urbansetnosy: + daniel.urban
2013-09-28 20:42:41terry.reedysetversions: + Python 3.4, - Python 3.3
2013-09-22 13:22:44grahamdcreate