[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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com