[Python-ideas] new pickle semantics/API

Collin Winter collinw at gmail.com
Fri Jan 26 00:39:58 CET 2007

On 1/25/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> "tomer filiba" <tomerfiliba at gmail.com> wrote:
> > repr is made for humans of course, while serialization is
> > made for machines. they serves different purposes,
> > so they need different APIs.
> I happen to disagree.  The only reason to use a different representation
> or API is if there are size and/or performance benefits to offering a
> machine readable vs. human readable format.
> I'm know that there are real performance advantages to using (c)Pickle
> over repr/unrepr, but I use it also so that I can change settings with
> notepad (as has been necessary on occasion).
> > all i'm after is the state of the object (which is expressed in terms of
> > other, more primitive objects).
> Right, but as 'primative objects' go, you cant get significantly more
> primitive than producing a string that can be naively understood by
> someone familliar with Python *and* the built-in Python parser.
> Nevermind that it works *today* with all of the types you specified
> earlier (with the exception of file objects - which you discover on
> parsing/reproducing the object).

You use pickle because it's more general than repr/unrepr, not because
it's faster or the result is smaller. Assuming you're talking about
the ConfigObj's unrepr mode

The types that unrepr can work with are :

    strings, lists tuples
    None, True, False
    dictionaries, integers, floats
    longs and complex numbers

You can't store classes, types or instances.

Pickle -- and the simplification API Tomer is proposing -- is far more
general than that. repr/unrepr is in no way a substitute.

Collin Winter

More information about the Python-ideas mailing list