On 1/25/07, Josiah Carlson <jcarlson@uci.edu> wrote:
"tomer filiba" <tomerfiliba@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