[Gary Poster, on pickle "extension codes"]
> Yes, I remembered this, and just refreshed my memory. This is the last
> mention I see in the archives as to ZODB use of protocol 2 (i.e., it
> doesn't, and prior to Py 2.3.4 it couldn't).
>
> http://mail.zope.org/pipermail/zodb-dev/2004-December/008259
...
>>> ...have we just committed a pickle containing all of 'a'?...
>> If `a` is persistent, yes.
> If not?
Then get_transaction().commit() presumably doesn't do much of anything,
since no persistent object was changed. It's like asking what this does:
i = 2+3
get_transaction().commi
On Dec 1, 2005, at 12:04 PM, Tim Peters wrote:
Note that we have yet to use a new strategy for shrinking pickle
sizes: a
few years ago Python's pickle code grew support for "extension
codes", a
registry of class/type names that _can_ be referenced by short (as
short as
2 bytes) new pickle
On 12/1/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Jürgen Herrmann]
> > the question was wether DateTime instances (of the new implementation,
> > which is yet to be coded) should mixin Persistent.
>
> OK. Since ZODB doesn't care whether you do
Well, I think that was the question. Does ZODB car
Tim Peters wrote:
There is only one commit in the following, so I'll assume you intended a
second commit at the end:
yes, *sigh*, must engage brain...
a.someTime = DateTime()
get_transaction().commit()
Is `a` persistent? I'm assuming that it is.
Yes.
...wait/do stuff...
a.someTime = Da
[Gary Poster]
> For some definition of "a lot of thought". :-) The pickle for pytz.utc
> is now relatively small (though still adds a non-trivial percentage
> addition--30%ish?--to a naive datetime IIRC). That's as far as that bit
> goes.
A naïve datetime has an extraordinarily small state, tho
[Chris Withers]
> Sorry, my question was that if DateTime's were persistent, would the
> following code result in a complete pickle for 'a' being written on the
> second transaction commit?
There is only one commit in the following, so I'll assume you intended a
second commit at the end:
> a.some
On Dec 1, 2005, at 11:39 AM, Chris Withers wrote:
Sorry, my question was that if DateTime's were persistent, would
the following code result in a complete pickle for 'a' being
written on the second transaction commit?
a.someTime = DateTime()
get_transaction().commit()
wait/do stuff...
On Dec 1, 2005, at 11:38 AM, Tim Peters wrote:
... I know Gary Poster gave a lot of thought to making pickles for
the timezone info in Zope3 efficient too.
For some definition of "a lot of thought". :-) The pickle for
pytz.utc is now relatively small (though still adds a non-trivial
perc
Tim Peters wrote:
Sorry, I couldn't find a comprehensible question here after reasonable
effort to extract one. Clearly, Zope2's DateTime.DateTime.DateTime objects
are neither persistent nor do they define any mutating methods. Are those
relevant? If not, try to ask a question directly, withou
[Jürgen Herrmann]
> the question was wether DateTime instances (of the new implementation,
> which is yet to be coded) should mixin Persistent.
OK. Since ZODB doesn't care whether you do, is there confusion about what
ZODB may or may not do in either case? That is, what's the ZODB issue here?
H
the question was wether DateTime instances (of the new implementation,
which is yet to be coded) should mixin Persistent.
regards, juergen herrmann
[ Tim Peters wrote:]
> Sorry, I couldn't find a comprehensible question here after reasonable
> effort to extract one. Clearly, Zope2's DateTime.Dat
[Chris Withers]
> Yay! Where's the correct place to report these nowadays?
Same as always: ZODB bugs should be reported on a Zope Collector, with
topic Database.
It's fine to discuss them on zodb-dev, but when (as appears to be the case
with this one) nobody has an immediate answer or time to di
Sorry, I couldn't find a comprehensible question here after reasonable
effort to extract one. Clearly, Zope2's DateTime.DateTime.DateTime objects
are neither persistent nor do they define any mutating methods. Are those
relevant? If not, try to ask a question directly, without assuming everyone
Yay! Where's the correct place to report these nowadays?
cheers,
Chris
Dieter Maurer wrote:
Chris Withers wrote at 2005-11-29 14:33 +:
Hot on the heals of my posts about "Shouldn't load state for" comes the
eagerly awaited sequel "Couldn't load state for" ;-)
...
File "lib/python/ZEO/z
15 matches
Mail list logo
