enhancement request: make py3 read/write py2 pickle format

Irmen de Jong irmen.NOSPAM at xs4all.nl
Wed Jun 10 13:34:05 EDT 2015


On 10-6-2015 11:36, Steven D'Aprano wrote:
>> For most apps, the alternatives are better. Irmen's serpent library is
>> strictly better on every front, for example. (Except potentially
>> security, who knows.)
> 
> Beyond simple needs, like rc files, literal_eval is not sufficient. You 
> can't use it to deserialise arbitrary objects. That might be a feature, but 
> if you need something more powerful than basic ints, floats, strings and a 
> few others, literal_eval will not be powerful enough.

Just to have this off my chest:

I guess that "serialization format" is not the most correct term for what serpent does
(or in general, for the literal expressions that literal_eval accepts). Serpent doesn't
strive to (de)serialize everything perfectly. It is meant as a pythonic data transfer
format.

You can do this by explicitly mapping your application's object model to and from the
wire data format, or do it in a more pythonic way (IMO) and let python take care of most
of it automatically. Serpent is smart (I hope) about a number of non-primitive types. If
needed, use its hooks to teach it about types it doesn't readily recognize.
Yes, it does force you to reduce the arbitrary types you want to process to the set of
types that are accepted in a python literal expression. Thankfully lists, sets, tuples
and dicts are also among them.


Raison d'être for serpent is that I was looking for a safe pythonic alternative for
pickle, and with fewer limitations than Json.   I chose to use ast.literal_eval from the
standard library to do the "deserialization" for me, and so only had to build some code
to "serialize" object trees into python literal expressions :)

Regarding security: I simply trust the docstring of ast.literal_eval here;
"Safely evaluate an expression node or a string containing a Python expression. [...]"


Irmen





More information about the Python-list mailing list