python persistence

[castironpi at gmail.com]

On Apr 1, 3:21 pm, castiro... at gmail.com wrote:
> On Apr 1, 11:34 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
> wrote:
>
>
>
>
>
> > En Tue, 01 Apr 2008 08:47:33 -0300, <castiro... at gmail.com> 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?- Hide quoted text -

Can you pickle a generator?  The only thing I know is:

>>> pickle.loads( pickle.dumps( k ) )
TypeError: object.__new__(generator) is not safe, use
generator.__new__()
>>> type( 'A',( generator, ),{})
TypeError: type 'generator' is not an acceptable base type

I bet there's a workaround on this one, how bulky is it?  Can you
shelve a frame?  Separate threads can access a generator, so long as
they wrap their calls: synchronous( next, a ); synchronous( a.send,
'xyz' )