On Apr 1, 11:34 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Tue, 01 Apr 2008 08:47:33 -0300, <[EMAIL PROTECTED]> escribió:
>
> >> >>>> c['0']= type('None',(),{})
> >> > Traceback (most recent call last):
> >> > pickle.PicklingError: Can't pickle <class '__main__.None'>: it's not
> >> > found as __main__.None
>
> >> Don't do that then. Or use the available pickle hooks to customize how
> >> such classes may be pickled. All persistence mechanisms have
> >> limitations.
>
> > I don't see a problem with that; except that binaries come from
> > disks. You could have a Python session that runs entirely on disks +
> > the ALU.
>
> (ALU? Do you mean CPU?) I don't understand this. Most programs are read
> from disk. Most data is read from disk.
>
> > I want to know if any, and correct me here, simple
> > modification can store live objects. I call a.append(it) and the
> > memory update takes place on disk instead.
>
> Using ZODB, a.append(it) would mark `a` as dirty. When you latter commit
> the transaction, it is stored back on disk.
>
> > If you require that all objects referenced by on-disk objects be on-
> > disk, that's an easy workaround.
>
> ZODB already does that.
It's pretty close, but the database connection can get bulky. If you
had:
_______________________
| ______________________
|File | PyOb1 | PyOb2 | .. |
| |_______|_______|______|
|_______________________
on disk, updating the reference counts and attributes would take a
long time, but it's just right for some core applications.
Strictly, I'm not in the "real" programming world, so if it's just a
few free steps to a database then I'm speculating. If it's not, then
writing database code needlessly complicates programs in some cases.
A default implementation might even take an explicit destroy
statement, essentially being a run-time swap file or random-access
pickles.
A possibility is to launch a manager in a separate process, so authors
don't have to bother with writeback. I'm actually almost looking at
off-loading protocols on this one. Cache is guaranteed to be up to
date, so cache a file in memory, and manipulate it so it has Python
bits. The object comes to survive the program. Call stack is still
in volatile.
> Using ZODB, a.append(it) would mark `a` as dirty. When you latter commit
> the transaction, it is stored back on disk.
Python changes are committed on line. ZODB does -not- do that. A
pretty close change would be:
Open file
Interpret file as generator, halted at yield but started,
Call send and next
What does the code for that look like?
--
http://mail.python.org/mailman/listinfo/python-list
