Guido van Rossum wrote:
In my blog I wrote:
Let's get rid of unbound methods. When class C defines a method f, C.f should just return the function object, not an unbound method that behaves almost, but not quite, the same as that function object. The extra type checking on the first argument that unbound methods are supposed to provide is not useful in practice (I can't remember that it ever caught a bug in my code) and sometimes you have to work around it; it complicates function attribute access;
I think this is probably a good thing as it potentially avoids some unintential aliasing.
and the overloading of unbound and bound methods on the same object type is confusing. Also, the type checking offered is wrong, because it checks for subclassing rather than for duck typing.
duck typing?
This is a really simple change to begin with:
*** funcobject.c 28 Oct 2004 16:32:00 -0000 2.67 --- funcobject.c 4 Jan 2005 18:23:42 -0000 *************** *** 564,571 **** static PyObject * func_descr_get(PyObject *func, PyObject *obj, PyObject *type) { ! if (obj == Py_None) ! obj = NULL; return PyMethod_New(func, obj, type); }
--- 564,573 ---- static PyObject * func_descr_get(PyObject *func, PyObject *obj, PyObject *type) { ! if (obj == NULL || obj == Py_None) { ! Py_INCREF(func); ! return func; ! } return PyMethod_New(func, obj, type); }
There are some test suite failures but I suspect they all have to do with checking this behavior.
Of course, more changes would be needed: docs, the test suite, and some simplifications to the instance method object implementation in classobject.c.
Does anyone think this is a bad idea?
It *feels* very disruptive to me, but I'm probably wrong. We'll still need unbound builtin methods, so the concept won't go away. In fact, the change would mean that the behavior between builtin methods and python methods would become more inconsistent. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org