[Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk

[Jim Jewett]

[Regarding a proposal to persist and resume the current application state]

On Mon, Sep 19, 2011 at 7:52 PM, Spectral One <ghostwriter402 at gmail.com> wrote:

> The only way I could see something like this working is on a closed system,

Neither Lisp nor Smalltalk are entirely closed, but ... they are
certainly more closed-world in practice than other languages are in
practice.

> s.t. there are no assumptions or interactions (files open/locked, external
> window managers/states, etc.) that cannot be fully accounted for by the
> values of the system itself.

That was in fact the case for everything I ever actually cared to persist.

The primary use case was an extended interactive-shell exploration,
rather than a server process.  (A secondary use case was
checkpointing, but that already took a bit of work to ensure your
program would pause and give you a chance to take that checkpoint.)

A third use case was faster testing of updated code, but I'm not
certain that was a net gain against the possibility of having multiple
versions of a function alive simultaneously.

> (You could theoretically attempt to record the
> information not available form interrogating the current state as such are
> declared, but there would be lots of room for errors, and, even then, no
> guarantees.)

Some information is already recorded for garbage collection, and for
good error reports; it really doesn't take all that much more.

> I don't think Python is the correct place to attempt such a thing. This
> sounds more like a VM- or OS-level affair, to me.

-jJ