On Tue, Jun 9, 2015 at 8:52 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Wednesday 10 June 2015 10:47, Devin Jeanpierre wrote: > >> Passing around data that can be put into ast.literal_eval is >> synonymous with passing around data taht can be put into eval. It >> sounds like a trap. > > In what way?
I misspoke, and instead of "synonymous", meant "also means". (Implication, not equivalence.) >> For human readable serialized data, text format protocol buffers are >> seriously underrated. (Relatedly: underdocumented, too.) > > Ironically, literal_eval is designed to process text-format protocols using > human-readable Python syntax for common data types like int, str, and dict. "Protocol buffers" are a specific technology, not an abstract concept, and literal_eval is not a great idea. * the common serializer (repr) does not output a canonical form, and can serialize things in a way that they can't be deserialized * there is no schema * there is no well understood migration story for when the data you load and store changes * it is not usable from other programming languages * it encourages the use of eval when literal_eval becomes inconvenient or insufficient * It is not particularly well specified or documented compared to the alternatives. * The types you get back differ in python 2 vs 3 For most apps, the alternatives are better. Irmen's serpent library is strictly better on every front, for example. (Except potentially security, who knows.) At least it's better than pickle, security wise. Reliability wise, repr is a black hole, so no dice. :( -- Devin -- https://mail.python.org/mailman/listinfo/python-list
