[Python-Dev] Getting rid of unbound methods: patch available

[Guido van Rossum]

[Guido]
> >   def test_im_class():
> >       class C:
> >           def foo(self): pass
> > -     verify(C.foo.im_class is C)

[Glyph]
> ^ Without this, as JP Calderone pointed out earlier, you can't serialize
> unbound methods.  I wouldn't mind that so much, but you can't tell that
> they're any different from regular functions until you're
> *de*-serializing them.

Note that you can't pickle unbound methods anyway unless you write
specific suppport code to do that; it's not supported by pickle
itself.

I think that use case is weak. If you really have the need to pickle
an individual unbound method, it's less work to create a global helper
function and pickle that, than to write the additional pickling
support for picking unbound methods.

> In general I like the patch, but what is the rationale for removing
> im_class from functions defined within classes?

The information isn't easily available to the function. I could go
around and change the parser to make this info available, but that
would require changes in many places currently untouched by the patch.

[Nick]
> I'm a little concerned about the modification to pyclbr_input.py, though (since
> it presumably worked before the patch). Was the input file tweaked before or
> after the test itself was fixed? (I'll probably get around to trying out the
> patch myself, but that will be on Linux as well, so I doubt my results will
> differ from yours).

It is just a work-around for stupidity in the test code, which tries
to filter out cases like "om = Other.om" because the pyclbr code
doesn't consider these. pyclbr.py hasn't changed, and still doesn't
consider these (since it parses the source code); but the clever test
in the test code no longer works.

> The other question is the pickling example - an unbound method currently stores
> meaningful data in im_class, whereas a standard function doesn't have that
> association. Any code which makes use of im_class on unbound methods (even
> without involving pickling)is going to have trouble with the change. (Someone
> else will need to provide a real-life use case though, since I certainly don't
> have one).

Apart from the tests that were testing the behavior of im_class, I
found only a single piece of code in the standard library that used
im_class of an unbound method object (the clever test in the pyclbr
test). Uses of im_self and im_func were more widespread. Given the
level of cleverness in the pyclbr test (and the fact that I wrote it
myself) I'm not worried about widespread use of im_class on unbound
methods.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)