Dreams.
Scott Dossey
sdossey at dolphin.openprojects.net
Sat Jul 10 19:13:02 EDT 1999
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
More information about the Python-list
mailing list