RevertableObject, RevertableDict and etc documentation

[rivvil]

Hello. I'm a newbie Ren'Py programmer and just discovered that my Python classes should inherit renpy.store.object to be able to rollback properly. Then I searched Ren'Py sources and found RevertableObject, RevertableDict and other similar classes.
So, is there any documentation about these classes? Or maybe some guru can explain when and how they should be used? What public aliases do they have?
For instance, I assume that RevertableDict should be used instead of standard Python dict to enable rollback functionality for this kind of objects. Am I right or not?

[PyTom]

The answer is yes, but Ren'Py does this for you automatically, when you're in a Ren'Py (.rpy, rather than .py) context. For example, in .rpy code,

Code: Select all

{ "foo" : "bar", "bar" : "baz", "baz" : "foo" }

creates a RevertableDict, rather than a dict. Similarly, in the Ren'Py context, object is bound to RevertableObject. So unless you plan on writing python code in a .py file, there's no need to use the names in renpy.python directly. If you are using .py files, you should inherit from (and create) renpy.store.object, renpy.store.list, renpy.store.dict, and renpy.store.set.

[rivvil]

PyTom, thank you for the answer.
I was about to refactor major portion of my code in a rollback sake but these implicit bindings saved my day It's a very nice feature I think.

[caryoscelus]

So basically everything in minstore.py should be imported in .py files (that would add 'sorted' and 'range' to the list)? And does this also mean that using something beyond those (even from standard library, e.g. collections) may break rollback or saving?

For now i'm using following code for Ren'Py/pure python compatibility. (This still requires to manually write "class A(object):" and literals like {} will always use builtin python..)

Code: Select all

try:
    from renpy.store import object, list, dict, set, range, sorted
    HAS_RENPY = True
except ImportError:
    HAS_RENPY = False

[trooper6]

About inheriting from object, should it be A:

Code: Select all

class Item(object)

or

Code: Select all

class Item(renpy.store.object)

what's the difference between the two? Is there a difference?

[xela]

If you are in .py file, object will be referenced to the original Python's object. Ren'Pys object (which I believe facilitates rollback and allows setting attributes directly) can be found at renpy.store.object (assuming you've imported it to the module).

In .rpy file, there is absolutely no difference between the two. Original Python's object is referenced at _object on global namespace.

*Edit: About an year ago a friend wrote some python code for my game and it failed to load after putting it into .rpy file because Ren'Py was using older sets that lacked one or two methods. That was the only time code written for Python 2.7 failed to load in Ren'Py at face value, maybe that is now fixed. There is virtually no difference that I am aware of otherwise... other than that you can do:

Code: Select all

obj = object()
obj.attr = "Meow"

with Ren'Pys object but not with pythons one (should throw an error) and the rollback thing. I usually use original stuff since my game doesn't require rollback.

[caryoscelus]

About inheriting from object, should it be A:

Code: Select all

class Item(object)

or

Code: Select all

class Item(renpy.store.object)

what's the difference between the two? Is there a difference?

Well, renpy.store.object is only available when the code is run in Ren'Py. In .rpy it's available by default and object is pointing to it as well. In .py it should be imported manually, so i'm using the code above to use the same code with and without Ren'Py. So there isn't much meaning in writing Item(renpy.store.object) unless you want to have both Ren'py and simple objects.

[PyTom]

Rollback won't work right with code in .py files.

When compling .rpy files, Ren'Py rewrites the python code in a number of ways. For example, the code.

Code: Select all

a = [ 1, 2, 3, 4 ]

becomes

Code: Select all

a = _revertable_list([1, 2, 3, 4])

(I'm going from memory, and the actual transformation takes place on the python AST.)

You can create immutable objects in python code, but if you want rollback to work right, put your code in an init python block. There's only so much magic to go around.

[caryoscelus]

Rollback won't work right with code in .py files.

Hmm, maybe i wasn't quite clear. I meant not using objects created in .py directly, but creating objects in .rpy from classes in .py. Rollback does seem to work as long as all classes are subclasses of renpy.store.* classes.

Unfortunately trick with multiple inheriting (renpy.store.object and some "plain python" class) doesn't work, so any library classes would fail to rollback.

[PyTom]

I'm pretty clear what I mean. The rollback system has a lot of code transformations in it, and these are required to make it work. You can't expect it to work for arbitrary Python code, at least not without reading and understanding renpy.python.WrapNode.