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

[Glyph Lefkowitz]

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 ;-).