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

[Guido van Rossum]

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)