[Python-Dev] Should we do away with unbound methods in Py3k?
Christian Heimes
lists at cheimes.de
Sat Nov 24 08:10:31 CET 2007
Guido van Rossum wrote:
>
> Index: Objects/funcobject.c
> ===================================================================
> --- Objects/funcobject.c (revision 59154)
> +++ Objects/funcobject.c (working copy)
> @@ -643,8 +643,10 @@
> static PyObject *
> func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
> {
> - if (obj == Py_None)
> - obj = NULL;
> + if (obj == Py_None || obj == NULL) {
> + Py_INCREF(func);
> + return func;
> + }
> return PyMethod_New(func, obj, type);
> }
>
> [well, except those should be tabs not spaces]
I've created a preliminary patch. Several unit tests are still failing.
The patch is also changing some semantics. For example in Python 2.5:
>>> import inspect
>>> class Class(object):
... def method(self): pass
...
>>> inspect.ismethod(Class().method)
True
>>> inspect.ismethod(Class.method)
True
But in py3k:
>>> import inspect
>>> class Class:
... def method(self): pass
...
>>> inspect.ismethod(Class().method)
True
>>> inspect.ismethod(Class.method)
False # !!!
Without support from the descriptor it's not possible to distinguish a
function from an unbound method any more. I like to add im_class to the
function object. I don't see negative side effects, do you?
/* Bind a function to an object */
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
if (obj == Py_None || obj == NULL) {
Py_INCREF(func);
if (type) {
PyObject_SetAttrString(func, "im_class", type);
}
else {
PyObject_SetAttrString(func, "im_class", Py_None);
}
return func;
}
return PyMethod_New(func, obj, type);
}
http://bugs.python.org/issue1493
Christian
More information about the Python-Dev
mailing list