On 11.06.15 02:58, Chris Angelico wrote:
On Thu, Jun 11, 2015 at 8:10 AM, 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 -- e.g.
it's why doctest fails badly at examples involving dictio
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)
Snipped aplenty.
On Wed, Jun 10, 2015 at 8:21 PM, Steven D'Aprano 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
>> a day.
>
>
Devin Jeanpierre :
> 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 substantially, as long
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 way
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 fra
On Wed, Jun 10, 2015 at 4:46 PM, Terry Reedy wrote:
> On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
>>
>> On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy 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
On Thu, Jun 11, 2015 at 8:10 AM, 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 -- e.g.
> it's why doctest fails badly at examples involving dictionaries. Text
> format protocol buffers
On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy 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
You commented a
On Wed, Jun 10, 2015 at 4:39 PM, Devin Jeanpierre
wrote:
> On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy 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 br
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy 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 string repre
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
serial
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 and
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 D'Apran
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
On 2015-06-10 13:08, Marko Rauhamaa wrote:
Robert Kern :
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 fo
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:
Robert Kern :
> 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 claims that its
> con
On Wed, Jun 10, 2015 at 9:04 PM, Neal Becker 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
> this safely?
I
On 2015-06-10 12:04, Neal Becker wrote:
Chris Warrick wrote:
On Tue, Jun 9, 2015 at 8:08 PM, 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 s
Chris Warrick wrote:
> On Tue, Jun 9, 2015 at 8:08 PM, 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
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 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
On Tue, Jun 9, 2015 at 8:52 PM, Steven D'Aprano
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 misspo
On Wed, Jun 10, 2015 at 1:57 PM, 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 text-format
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 syn
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 Wed, Jun 10, 2015 at 10:47 AM, 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.
Except that it's hugely restricted. There are JSON parsing libraries
all over the plac
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 pla
On 10-6-2015 1:06, Chris Angelico wrote:
> On Wed, Jun 10, 2015 at 6:07 AM, Devin Jeanpierre
> 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
On Wed, Jun 10, 2015 at 6:07 AM, Devin Jeanpierre
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, we switched to usin
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 propertie
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.
--
https://mail.python.org/mailman/lis
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 f
On Tue, Jun 9, 2015 at 1:08 PM, 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 re
On Tue, Jun 9, 2015 at 8:08 PM, 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 re
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
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 pickle
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 compatibil
39 matches
Mail list logo
