Dreams.

[Scott Dossey]

Okay, I am new to the newsgroup, but I thought I'd post something
interesting that I've just started working on, and get some feedback.  I've
been toying around with the idea of implementing "dreams" into the Python
source code.  

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. 

Before you start telling me about the numerous interaction problems this
will cause, and how impossible it will be to implement, think of what it
does to certain types of error handling!  You don't have to back out changes
when your change to a transactional database goes awry midway through the
change.  Even though functionality would be limited, (not all things could
or would be backed out), any automatic handling (even partial) of these
types of problems could be a huge blessing for certain types of programming.

Here's how I was thinking about implementing them (If you are not familiar
with python's C implementation this may be unfathomable to you):

The easiest way to do it that I can see is the following:
	      
	Step One:  Put a wrapper around each variable and function pointer
		in any PyObject and it's contained structures (IE,
		PyTypeObject), so that any reference to any object can be 
		"caught".  This would involve tweaks all over the python
		codebase to deal with the new way of accessing variables.
		I'll probably do this by changing the name and method of 
		access for everything inside a PyObject and letting the
		compiler find all the millions of references, then fixing these
		up to use the new wrappers.  It's too bad there are not access
		methods for all these things already, rather than being 
		indexed directly.

        Step Two:  Call pickling code inside those wrappers to save the
		state of the object before and after the calls.  Write the
		diffs out to the dream code so it can store it in a "dreamlog".
	        Deletions of objects will similarly "pickle" the objects and
 		store them in the dreamlog.  If a pickle of an object before
		it is referenced doesn't work, then
		"abort" the dream by restoring the state and
		throwing a "DreamException".
		
	Step Three:  Fix up more objects so they can be pickled, so that
		dreams are mode useful.  IE, make files pickleable, modules
		pickleable, text screen state and TK graphical screen state
		pickleable and restoreable, etc. 

	Step Four:  Major debugging, testing, and module usage documentation.
	
I'd probably include dreaming as a compile time option of python, since
support for it will cause some pretty significant code slowdown of python,
even when not "dreaming".

However, there are a couple of major problems with my approach:
1.	They break every C module known to man in a way that's not too hard
to fix, but will have to be done for every C module that is going to support
dreams.

2.  	Python will be slowed down.  Every call/variable reference 
	will have a little more overhead when not dreaming, A LOT when 
	dreaming.

3.	It's very invasive.

I'll take feedback in terms of ideas, problems, feasibility statements,
flames,  whatever.  Most of all, I want help!  I think this would add a very
interesting and useful feature to Python (as perhaps, a compile time option).
Guido, I know you're out there, your feedback would be most appreciated,
along with the feedback of any other Python maintainers.

-Scott Dossey
sdossey at armored.net, sdossey at openprojects.net