[Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method? (original) (raw)

Guido van Rossum guido at python.org
Sat Jun 12 21:59:54 CEST 2010

On Sat, Jun 12, 2010 at 10:19 AM, Philip Jenvey <pjenvey at underboss.org> wrote:

+1 on changing this, it's annoying for alternate implementations. They oftentimes implement functions in pure Python whereas user code might be expecting the PYCFunction behavior.

Jython's had a couple cases of this incompatibility reported. It's a rare occurrence but it's very mysterious to the user when it happens.

Well, yeah, but you're presenting an argument against changing this -- existing code will break if it is changed.

I can think of only way out without just breaking such code: Start issuing warnings when a bare PyCFunction exists at the class level, and introduce/recommend decorators that can be used to disambiguate the two possible intended meanings.

As Brett says, f = staticmethod(func) will work to insist on the existing PyCFunction semantics. We should also introduce a new one decorator that treats any callable the same way as pure-Python functions work today: bind the instance to the first argument when it is called on an instance. I can't think of a good name for that one right now, but we'll think of one.

I wish the warning could happen at class definition time, but I expect that there are use cases where the warning is unnecessary (because the code happens to be structured so as to never call it through the instance) or even wrong (who knows what introspection might be thwarted by wrapping something in staticmethod). Perhaps the warning can be done by adding a get method to PyCFunction that issues the warning and then returns the original value.

I'm not sure how we'll ever get rid of the warning except in Py4k.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list