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>
> > 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 [snip].

My intentions may be pedagogical but I can guarantee good.  I am
following the cases where databases are way-out-of-proportion
techniques, and you only need small numbers persistent.

I am looking for a step-by-step of everything that happens in line one
of the following program:

#!/windows
a= [ ]

What c-l-py says is that the compilation flags vary widely enough to
make my destination worthless.  Accepting concern, please only reply
in readers' free time.

I expect I wish to override routines and macros which are buried
pretty deep and used pretty pervasively throughout Python and inner
user extension modules, so I'll reemphasize that I'm only interested
in pass-time hobbyage.  Consultants need not reply (but of course
may).

I foresee that writing my own disk-based-heap may be in order, which
would be why Bruno keeps directing us to relationals.  I would want an
arena file/pool file.

Zoom out to the big picture:

Session 1:

>>> managingfolder= '/live/Python/'
>>> manager['a']= [ 0 ]

Session 2:

>>> managingfolder= '/live/Python/'
>>> manager['a']
[ 0 ]
>>> manager['a'].append( 0 )

Session 3:

>>> managingfolder= '/live/Python/'
>>> manager['a']
[ 0, 0 ]

I would kind of expect a file per the diagram in obmalloc.c, and I
expect to specialize in CPython.

        Object-specific allocators
    _____   ______   ______       ________
   [ int ] [ dict ] [ list ] ... [ string ]       Python core
|
+3 | <----- Object-specific memory -----> | <-- Non-object memory -->
|


struct pool_header and struct arena_object would probably appear, and
to explify priorities, performance would be a low priority, and it's a
high priority to stay all in Python.  (Aside, I certainly would
maintain Python is yes, still Python.)