adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Script state saving


From: Kai Sterker
Subject: [Adonthell-devel] Script state saving
Date: Tue, 21 May 2002 15:51:47 +0200

I finally had a closer look at saving/loading the state of a python
script (for example a schedule). The bad news is, pickle/cPickle won't
work for us.

First of all, the two only have a python interface, but saving is done
on C++ side. They would also have trouble with our wrapped classes (as
those point to their corresponding C++ object, which can't be pickled).


An alternative would be to write explicit put-/getstate methods for each
script. They could be tailored to the script, but it means a lot more
work. Since most of the class members in need of saving will be integers
(maybe a few strings as well), I have another idea:

To save the script state, we could simple go through the class' __dict__
and save any string or int we find. When loading, we can simple add them
to __dict__ again. That can be done from C++ side, and it can be done
for any script we have. And we can easily add support for other types if
we ever need them.

In fact, it's nearly the same as what you've done with the argument
saving, Alex. The only difference is that we're saving a dictionary
instead of a tuple. Which makes me wonder whether a py_object::put_state
function shouldn't rather take care of saving (and loading) everything:
the script and class name, the script's arguments and the script state.

That way, a lot of identical code could be avoided. The py_object class
is the perfect place to centralize that stuff.


As far as the implementation goes, put_state would write filename, class
name, arguments (strings and ints only) and __dict__ (again strings and
ints only). The get_state method would have an optional argument to
allow passing of non-ints/strings. It would load filename, class and
arguments. Then instanciate the python class with those arguments and
finally load the class state.

The only issue is that most likely some of the script arguments will be
saved twice, as they'll also be contained in __dict__. But as they are
needed for the constructor, I see no way around this. (Unless the saved
data could be created without invoking the script in the first place.
Then stuff that gets saved with the class state needs never be passed to
the class at construction time. But that would require proper tools ;).)


Anyway, what do you think? Shall I go ahead?

Kai



reply via email to

[Prev in Thread] Current Thread [Next in Thread]