enhancement request: make py3 read/write py2 pickle format

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Jun 10 05:36:56 EDT 2015


On Wednesday 10 June 2015 14:48, Devin Jeanpierre wrote:

[...]
> 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

For literals, the canonical form is that understood by Python. I'm pretty 
sure that these have been stable since the days of Python 1.0, and will 
remain so pretty much forever:

ints: 12345
floats: 1.2345
strings: "spam"
None
True
False
lists, tuples, dicts and sets containing the above

There may be a few differences between Python 2 and 3, e.g. no set literal 
in Python 2, but in general the Python syntax is well-known and understood 
by anyone programming in Python.


> * there is no schema
> * there is no well understood migration story for when the data you
>   load and store changes

literal_eval is not a serialisation format itself. It is a primitive 
operation usable when serialising. E.g. you might write out a simple Unix-
style rc file of key:value pairs:


length=23.45
width=10.95
landscape=False

split on "=" and call literal_eval on the value.

This is a perfectly reasonable light-weight solution for simple 
serialisation needs.


> * it is not usable from other programming languages

That's okay, we're not writing in other programming languages :-)


> * it encourages the use of eval when literal_eval becomes inconvenient
>   or insufficient

I don't think so. I think that people who make the effort to import ast and 
call ast.literal_eval are fully aware of the dangers of eval and aren't 
silly enough to start using eval.


> * It is not particularly well specified or documented compared to the
>   alternatives.
> * The types you get back differ in python 2 vs 3

Doesn't matter. The type you *write* are different in Python 2 vs 3, so of 
course you do.


> 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.

I think we are in violent agreement :-)

-- 
Steve




More information about the Python-list mailing list