On Mon, 2005-01-17 at 07:43 -0800, Guido van Rossum wrote:
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.
It's supported by Twisted. Alternatively, replace "pickle" with "python object serializer of my design" - I am concerned both about useful information being removed, and about specific features of Pickle.
Twisted's .tap files have always pushed the limits of pickle. I don't remember why my users wanted this specific feature - the code in question is almost 3 years old - but when you think of a pickle as a self-contained universe of running Python objects, any plausible reason why one might want a reference to an unbound method in code becomes a reason to want to serialize one.
The only time I've used it myself was to pickle attributes of interfaces, which I no longer need to do since zope.interface has its own object types for that, so it's not really _that_ important to me. On the other hand, if PJE's "monkey typing" PEP is accepted, there will probably be lots more reasons to serialize unbound methods, for descriptive purposes.
I think that use case is weak.
It's not the strongest use-case in the world, but is the impetus to remove unbound method objects from Python that much stronger? I like the fact that it's simpler, but it's a small amount of extra simplicity, it doesn't seem to enable any new use-cases, and it breaks the potential for serialization.
In general, Pickle handles other esoteric, uncommon use-cases pretty well:
>>> x =  >>> y = (x,) >>> x.append(y) >>> import cPickle >>> cPickle.dumps(x) '(lp1\n(g1\ntp2\na.' >>> x [([...],)]
since when you need 'em, you really need 'em.
Method objects were previously unsupported, which is fine because they're pretty uncommon. Not only would this patch continue to not support them, though, it makes the problem impossible to fix in 3rd-party code. By removing the unbound method type, it becomes an issue that has to be fixed in the standard library. Assuming that 3rd party code will not be able to change the way that functions are pickled and unpickled in cPickle, in python2.5.
Ironically, I think that this use case is also going to become more common if the patch goes in, because then it is going to be possible to "borrow" functionality without going around a method's back to grab its im_func.
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.
This isn't true if you've already got the code written, which I do ;-).