[Python-Dev] Should we do away with unbound methods in Py3k?

[Phillip J. Eby]

At 08:19 PM 11/22/2007 -0800, Guido van Rossum wrote:
>It looks like we're in agreement to drop unbound methods and have a
>reasonable set or arguments around it (e.g. keep staticmethod, no
>changes to methods of builtin types, etc.). Do we need a PEP? It's
>essentially a 2-line change in funcobject.c (func_descr_get()) -- plus
>fixing up half a dozen or so unittests that specifically seem to test
>the behavior of unbound methods.

Since the only meaningful difference between an unbound method and a 
function is the availability of the im_class attribute, I Googled 
'im_class ext:py' to see what's using it.  There were 314 hits uses 
in published code, and I skimmed the first 60 or 70 of those.

Of the ones I looked at, relatively few actually do anything with 
unbound methods specifically.  Most are just custom pickling or 
persistence for methods, or method replacements like a "weakref 
method" that doesn't keep a strong reference to im_self.

However, a few uses relevant to unbound methods turned up, 
however.  Some documentation tools, an AOP library, an xreload()-like 
module reloader from Enthought, plus one usage in the stdlib.

There were also a few modules where it was difficult to tell if 
unbound methods were actually important.  While for most of the 
documentation tools it was probably not relevant, there were some 
(like a method deprecation utility) that looked like they would lose 
functionality by not being able to get the im_class of an object.

The stdlib usage is in the unittest module: the test loading 
machinery needs to know the class of an unbound method so it knows 
what TestCase subclass to instantiate, when loading a single test by 
name.  This could probably be worked around by making the routine 
keep track of the object from which the target object was retrieved.

This is far from a comprehensive survey; 'UnboundMethodType ext:py' 
turns up 102 more hits, including another testing tool that uses 
unbound methods in a different way.  There are also usage patterns 
that can't easily be searched for.  For example, code that wants to 
be able to distinguish static methods and instance methods at the class level.

Most of these use cases could probably be worked around, with 
sufficient effort.  Many will probably have bigger problems porting 
to 3.0 than the absence of unbound methods.  And I don't personally 
have a horse in this race, as my own code is surprisingly free of im_class use.

Actually, given how many places my code is peppered with '.im_func' 
calls to *unwrap* unbound methods and reuse them in other classes, I 
probably lean more towards getting rid of them.  :)