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 -- https://mail.python.org/mailman/listinfo/python-list
