On 11.06.15 02:58, Chris Angelico wrote:
On Thu, Jun 11, 2015 at 8:10 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1, 'b': 2}. This can make tests brittle -- e.g.
it's why doctest fails badly at
On Thursday 11 June 2015 15:39, Devin Jeanpierre wrote:
But I'm not talking about re-inventing what already exists. If I want
JSON, I'll use JSON, not spend weeks or months re-writing it from
scratch. I can't do this:
class MyClass:
pass
a = MyClass()
serialised = repr(a)
b =
On Wed, Jun 10, 2015 at 9:04 PM, Neal Becker ndbeck...@gmail.com wrote:
I believe a good native serialization system is essential for any modern
programming language. If pickle isn't it, we need something else that can
serialize all language objects. Or, are you saying, it's impossible to do
On 2015-06-10 12:04, Neal Becker wrote:
Chris Warrick wrote:
On Tue, Jun 9, 2015 at 8:08 PM, Neal Becker ndbeck...@gmail.com wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use
Chris Warrick wrote:
On Tue, Jun 9, 2015 at 8:08 PM, Neal Becker ndbeck...@gmail.com wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It
Robert Kern robert.k...@gmail.com:
By the very nature of the stated problem: serializing all language
objects. Being able to construct any object, including instances of
arbitrary classes, means that arbitrary code can be executed. All I
have to do is make a pickle file for an object that
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
On Wed, Jun 10, 2015, at 08:08, Marko Rauhamaa wrote:
You can't serialize/migrate arbitrary objects. Consider open TCP
connections, open files and other objects that extend outside the Python
VM. Also objects hold references to each other, leading to a huge
reference mesh.
For example:
On 2015-06-10 13:08, Marko Rauhamaa wrote:
Robert Kern robert.k...@gmail.com:
By the very nature of the stated problem: serializing all language
objects. Being able to construct any object, including instances of
arbitrary classes, means that arbitrary code can be executed. All I
have to do is
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
FWIW most of the objections below also apply to JSON, so this doesn't
just have to be about repr/literal_eval. I'm definitely a huge
proponent of widespread use of something like protocol buffers, both
for production code and personal hacky projects.
On Wed, Jun 10, 2015 at 2:36 AM, Steven
Robert Kern wrote:
To allow people to write their own types that can be serialized,
you have to let them specify arbitrary callables that will do the
reconstruction. If you whitelist the possible reconstruction callables,
you have greatly restricted the types that can participate in the
On Wed, Jun 10, 2015 at 4:39 PM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1,
On Thu, Jun 11, 2015 at 8:10 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1, 'b': 2}. This can make tests brittle -- e.g.
it's why doctest fails badly at examples involving dictionaries. Text
On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1, 'b': 2}. This can make tests brittle
Not if one compares objects rather than string representations of
objects. I am strongly of the view that code
On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1, 'b': 2}. This can make tests brittle
On Wed, Jun 10, 2015 at 4:46 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
The problem is that there are two different ways repr might
On Wed, Jun 10, 2015, at 19:30, Gregory Ewing wrote:
If whitelisting a type is the *only* thing you need to
do to make it serialisable, I think that comes close
enough to the stated goal of being able to serialise
all [potentially serialisable] language objects.
IMO the serialization
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
The problem is that there are two different ways repr might write out
a dict equal to {'a': 1, 'b': 2}. This can make tests brittle
Not if one compares objects rather than
Snipped aplenty.
On Wed, Jun 10, 2015 at 8:21 PM, Steven D'Aprano st...@pearwood.info wrote:
On Thu, 11 Jun 2015 08:10 am, Devin Jeanpierre wrote:
[...]
I could spend a bunch of time writing yet another config file format,
or I could use text format protocol buffers, YAML, or TOML and call it
On Thu, 11 Jun 2015 08:10 am, Devin Jeanpierre wrote:
[...]
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:
The problem is that there are two different ways repr
Devin Jeanpierre jeanpierr...@gmail.com:
For example, one can also imagine testing that a serialized structure
is identical across version changes, so that it's guaranteed to be
forwards/backwards compatible. It is not enough to test that the
deserialized form is, because it might differ
On 09/06/2015 19:08, Neal Becker wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help if py3 could read/write py2
On Tue, Jun 9, 2015 at 8:08 PM, Neal Becker ndbeck...@gmail.com wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help
In a message of Tue, 09 Jun 2015 14:08:25 -0400, Neal Becker writes:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help if
On Tue, Jun 9, 2015 at 1:08 PM, Neal Becker ndbeck...@gmail.com wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help if py3 could read/write py2 pickle format.
You know, backward
On 09.06.15 21:31, Laura Creighton wrote:
We have an issue about that.
https://bugs.python.org/issue13566
Go there and say you want it too. :)
I afraid issue title is too general. :) The issue is only about one
minor detail of py3 to py2 compatibility.
--
On 09.06.15 21:08, Neal Becker wrote:
One of the most annoying problems with py2/3 interoperability is that the
pickle formats are not compatible. There must be many who, like myself,
often use pickle format for data storage.
It certainly would be a big help if py3 could read/write py2 pickle
There's a lot of subtle issues with pickle compatibility. e.g.
old-style vs new-style classes. It's kinda hard and it's better to
give up. I definitely agree it's better to use something else instead.
For example, we switched to using protocol buffers, which have much
better compatibility
On Wed, Jun 10, 2015 at 6:07 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
There's a lot of subtle issues with pickle compatibility. e.g.
old-style vs new-style classes. It's kinda hard and it's better to
give up. I definitely agree it's better to use something else instead.
For example,
On 10-6-2015 1:06, Chris Angelico wrote:
On Wed, Jun 10, 2015 at 6:07 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
There's a lot of subtle issues with pickle compatibility. e.g.
old-style vs new-style classes. It's kinda hard and it's better to
give up. I definitely agree it's better to
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.
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
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
On Wednesday 10 June 2015 13:57, random...@fastmail.us wrote:
On Tue, Jun 9, 2015, at 23:52, Steven D'Aprano wrote:
For human readable serialized data, text format protocol buffers are
seriously underrated. (Relatedly: underdocumented, too.)
Ironically, literal_eval is designed to process
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?
literal_eval will cleanly and safely refuse to evaluate strings like:
On Tue, Jun 9, 2015, at 23:52, Steven D'Aprano wrote:
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
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
On Wed, Jun 10, 2015 at 1:57 PM, random...@fastmail.us wrote:
On Tue, Jun 9, 2015, at 23:52, Steven D'Aprano wrote:
For human readable serialized data, text format protocol buffers are
seriously underrated. (Relatedly: underdocumented, too.)
Ironically, literal_eval is designed to process
39 matches
Mail list logo
