[Python-Dev] Should we do away with unbound methods in Py3k?
Phillip J. Eby
pje at telecommunity.com
Fri Nov 23 13:59:22 CET 2007
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. :)
More information about the Python-Dev