def test_im_class(): class C: def foo(self): pass
verify(C.foo.im_class is C)
^ 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.
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.