On Apr 1, 3:21 pm, [EMAIL PROTECTED] wrote:
> 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?- 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' )
--
http://mail.python.org/mailman/listinfo/python-list
