Michael Haggerty wrote:
Typically, the purpose of a database is to persist data across program
runs. So typically, your suggestion would only help if there were a way
to persist the primed Pickler across runs.
I don't think you need to be able to pickle picklers.
In the case in question, the
Guido van Rossum wrote:
> On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty wrote:
>> Typically, the purpose of a database is to persist data across program
>> runs. So typically, your suggestion would only help if there were a way
>> to persist the primed Pickler across runs.
>
> I haven't follo
On Sat, Mar 7, 2009 at 8:04 AM, Michael Haggerty wrote:
> Typically, the purpose of a database is to persist data across program
> runs. So typically, your suggestion would only help if there were a way
> to persist the primed Pickler across runs.
I haven't followed all this, but isn't is at lea
Greg Ewing wrote:
> Michael Haggerty wrote:
>> A similar effect could *almost* be obtained without accessing the memos
>> by saving the pickled primer itself in the database. The unpickler
>> would be primed by using it to load the primer before loading the record
>> of interest. But AFAIK there
Antoine Pitrou wrote:
If these strings are not interned, then perhaps they should be.
I think this is a different problem. Even if the strings are
interned, if you start with a fresh pickler each time, you
get a copy of the strings in each pickle. What he wants is
to share strings between diff
Michael Haggerty wrote:
A similar effect could *almost* be obtained without accessing the memos
by saving the pickled primer itself in the database. The unpickler
would be primed by using it to load the primer before loading the record
of interest. But AFAIK there is no way to prime new pickle
On Fri, Mar 6, 2009 at 10:01 AM, Michael Haggerty wrote:
> Antoine Pitrou wrote:
>> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>>> Antoine Pitrou wrote:
Michael Haggerty alum.mit.edu> writes:
> It is easy to optimize the pickling of instances by giving them
>
Antoine Pitrou wrote:
> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>> Antoine Pitrou wrote:
>>> Michael Haggerty alum.mit.edu> writes:
It is easy to optimize the pickling of instances by giving them
__getstate__() and __setstate__() methods. But the pickler still
Antoine Pitrou wrote:
> Michael Haggerty alum.mit.edu> writes:
>> It is easy to optimize the pickling of instances by giving them
>> __getstate__() and __setstate__() methods. But the pickler still
>> records the type of each object (essentially, the name of its class) in
>> each record. The spa
Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
> Antoine Pitrou wrote:
> > Michael Haggerty alum.mit.edu> writes:
> >> It is easy to optimize the pickling of instances by giving them
> >> __getstate__() and __setstate__() methods. But the pickler still
> >> records the type of
On Fri, Mar 6, 2009 at 5:45 AM, Antoine Pitrou wrote:
> If these strings are not interned, then perhaps they should be.
> There is a similar optimization proposal (w/ patch) for attribute names:
> http://bugs.python.org/issue5084
>
If I understand correctly, that would help with unpickling, but
Michael Haggerty alum.mit.edu> writes:
>
> It is easy to optimize the pickling of instances by giving them
> __getstate__() and __setstate__() methods. But the pickler still
> records the type of each object (essentially, the name of its class) in
> each record. The space for these strings cons
Collin Winter wrote:
> [...] I've found a few examples of code using the memo attribute ([1], [2],
> [3]) [...]
As author of [2] (current version here [4]) I can tell you my reason.
cvs2svn has to store a vast number of small objects in a database, then
read them in random order. I spent a lot of
Guido van Rossum wrote:
Then it'd be better to have a method clear_memo() on pickle objects.
You should have that anyway. I was just suggesting a
way of preserving compatibility with old code without
exposing all the details of the memo.
--
Greg
___
On Thu, Mar 5, 2009 at 1:36 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> This was a bad idea (*), and I'd be happy to ban it -- but we'd
>> probably have to bump the pickle protocol version in order to maintain
>> backwards compatibility.
>
> If you're talking about multiple calls to dump(
Guido van Rossum wrote:
This was a bad idea (*), and I'd be happy to ban it -- but we'd
probably have to bump the pickle protocol version in order to maintain
backwards compatibility.
If you're talking about multiple calls to dump() on the same
pickler, it might be a bad idea for a network con
Collin Winter wrote:
Reusing the Pickler without clearing the
memo will produce pickles that are, as best I can see, invalid
I'm not sure what you mean by "reusing the pickler" here,
and how it can produce an invalid pickle.
I think what the docs mean by it is continuing to pickle
objects to
On Thu, Mar 5, 2009 at 12:07 PM, Collin Winter wrote:
> I'm working on some performance patches for cPickle, and one of the
> bigger wins so far has been replacing the Pickler's memo dict with a
> custom hashtable (and hence removing memo's getters and setters). In
> looking over this, Jeffrey Yas
I'm working on some performance patches for cPickle, and one of the
bigger wins so far has been replacing the Pickler's memo dict with a
custom hashtable (and hence removing memo's getters and setters). In
looking over this, Jeffrey Yasskin commented that this would break
anyone who was accessing t
19 matches
Mail list logo
