[Python-Dev] Let's get rid of unbound methods

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org