On Wed, Jun 10, 2015 at 10:47 AM, Devin Jeanpierre <jeanpierr...@gmail.com> 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.
Except that it's hugely restricted. There are JSON parsing libraries all over the place, and one of the points in favour of JSON is that it can be dumped into JavaScript as-is and it evaluates correctly. Doesn't mean you have to use eval() to parse it, and usually you won't. > Other points against JSON / etc.: the lack of schema makes it easier > to stuff anything in there (not as easily as pickle, mind), and by > returning a plain dict, it becomes easier to require a field than to > allow a field to be missing, which is bad for robustness and bad for > data format migrations. (Protobuf (v3) has schemas and gives every > field a default value.) This is true. But there are plenty of cases where you can manage on a simple dictionary that maps keywords to values that are either strings, numbers, or lists/dicts of same - and without any schema to tell you what keywords are valid. It's simple, extensible, and scales reasonably well to mid-sized use cases. Sure, the biggest cases (and some of the smaller ones) benefit nicely from schema definitions, but there's room to manage without. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
