[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.
[snip]
> 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).
[snip]
> > 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
(http://www.voidspace.org.uk/python/configobj.html#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