[Python-ideas] new pickle semantics/API (original) (raw)

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