On Sat, Jun 12, 2010 at 10:19 AM, Philip Jenvey <pjen...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
