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. :)