[Python-ideas] new pickle semantics/API

tomer filiba tomerfiliba at gmail.com
Thu Jan 25 23:16:15 CET 2007

On 1/25/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> Overall, I like the idea; I'm a big fan of simplifying object
> persistence and/or serialization.  A part of me also likes how the
> objects can choose to lie about their types.
> But another part of me says; the basic objects that you specified
> already have a format that is unambiguous, repr(obj).  They also are
> able to be reconstructed from their component parts via eval(repr(obj)),
> or even via the 'unrepr' function in the ConfigObj module.  It doesn't
> handle circular referencse.

well, repr is fine for most simple things, but you don't use repr to
serialize objects, right? it's not powerful/introspective enough.
besides repr is meant to be readable, while __getstate__ can return
any object. imagine this:

class complex:
    def __repr__(self):
        return "(%f+%fj)" % (self.real, self.imag)
    def __getstate__(self):
        return self.__class__, (self.real, self.imag)

repr is made for humans of course, while serialization is
made for machines. they serves different purposes,
so they need different APIs.

> Even better, it has 3 native representations; repr(a).encode('zlib'),
> repr(a), pprint.pprint(a); each offering a different amount of user
> readability.  I digress.

you may have digressed, but that's a good point -- that's exactly
why i do NOT specify how objects are encoded as a stream of bytes.

all i'm after is the state of the object (which is expressed in terms of
other, more primitive objects).

you can think of repr as a textual serializer to some extent, that
can use the proposed __getstate__ API. pprint is yet another
form of serializer.

> I believe the biggest problem with the proposal, as specified, is that
> changing the semantics of __getstate__ and __setstate__ is a bad idea.
> Add a new pair of methods and ask the twisted people what they think.
> My only criticism will then be the strawman repr/unrepr.

i'll try to come up with new names... but i don't have any ideas
at the moment.


More information about the Python-ideas mailing list