Dreams.

[Tim Peters]

[Scott Dossey]
> ...
> What are dreams, you say?  Look at the following python code
> fragment for an idea, first of all, of how they are put into code:
>
> #START PSEUDOCODE FRAGMENT
> import sys
> import dreams
>
> aDream=dreams.dream()
> try:
> 	#Insert code here.
> except:
> 	aDream.wakeup()
> 	sys.exit(1)
>
> aDream.realize()
> #END PSEUDOCODE FRAGMENT
>
> The code, at the location denoted by "#Insert code here." would
> run, but if an exception was thrown, it will have been as if the
> code had "happened in a dream".  No variables will have been changed/
> deleted.  Nothing will have changed from before the "dream" in terms
> of Python's variable state.  Ideally, (but this is much harder), all
> file changes, all things that are "possible" to return to their
> original state, would be returned as well.
> (You can't take back network traffic).
>
> Dream.wakeup() would restore to the state before the dream, and continue
> execution from that line forward.  Dream.realize() would commit to the
> dream, stop saving change-state, and delete the change state it had
> already recorded.
> [and sketches an implementation based on changing code all over the
>  interpreter]

I expect you could get most of this with little effort and little cost under
Unix via fork and a little IPC:  fork the process and try the speculative
stuff in the child, while the parent waits for the child to tell it how
things turned out.  If the child is happy, it tells the parent to die; if
the child has a nightmare, it kills itself after telling the parent "it was
all a bad dream", and the parent goes on as if nothing had happened.  Modulo
problems with external resources (like files indeed), the semantics of fork
guarantee that neither process can affect the other's view of reality.

Another, more portable, but more difficult approach, is adding a
checkpoint/restart facility to Python.  Checkpoint the interpreter state at
the start of a dream, and either delete it or restart from it (as
appropriate) when the dream ends.  This may make every dream expensive to
try (depending on how much state there is to be saved away), but confines
the expense to the start & the end.  While the dream is in progress, or if
nobody is dreaming at all, everything runs as it does now.

Or ...

I'm encouraging you to think about other approaches only partially because
the one you have in mind sucks <wink>:  the chances of getting massive code
changes into the distributed Python these days are vanishingly small.  OTOH,
if you just want to play with it to see how it works out, Python's code base
is a pleasant one to play with!

who-would-take-your-dreams-away-
    takes-your-soul-another-day-ly y'rs  - tim