Ren'Py Multi persistent files in Ren'Py

[anne O'nymous]

[CODE]init python:
from renpy.persistent import _MultiPersistent
[/CODE]

Since you're in an init block, the import is useless. You already have natural access to renpy.persistent._MultiPersistent, like in fact to anything defined by the core. The import is only needed in pure Python files and for the modules you add yourself.


Edit:Messed the presentation, sorry

 

[the66]

well..

Spoiler: creating a MyMultiPersistent object w/o import

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: creating a MyMultiPersistent object with import

You don't have permission to view the spoiler content. Log in or register now.

thank god, i'm using some useless code

 

[anne O'nymous]

File "game/multipersistent.rpy", line 50, in MyMultiPersistent
rv = _MultiPersistent()
NameError: global name '_MultiPersistent' is not defined

Well, obviously that "_MultiPersistent" isn't a global name since it's an attribute of the persistent module which is itself an attribute of the renpy module. So, replace the line 50 by the right value :

rv = renpy.persistent._MultiPersistent()

And the error disappear...

 

[the66]

Well, obviously that "_MultiPersistent" isn't a global name since it's an attribute of the persistent module which is itself an attribute of the renpy module. So, replace the line 50 by the right value :

rv = renpy.persistent._MultiPersistent()

And the error disappear...

or i import it from renpy.persistent
but to make you happy.. i swear, i won't never ever import something from another renpy module again
i will rather use complete names

 

[anne O'nymous]

or i import it from renpy.persistent
but to make you happy.. i swear, i won't never ever import something from another renpy module again
i will rather use complete names

It's not a caprice, there's a reason behind this. When you import something, you copy it in the module/store where it's imported. So when you write :

    from renpy.persistent import _MutliPersistent

You create a store._MultiPersistent function, which not happen when you use it where it is.

In most of the case it's not a problem because it's a reference-like copy, plus here it's a function, so something intended to be static. But when it's object that you import it increase the number of reference and make the object not disappear when it should, because there's still your copy somewhere.

But the worse case is when it simply and silently overwrite what's already defined (in the console) :

id( Show )
id( renpy.ast.Show )

They are two different objects sharing the same name (there's a lot like this in the core). Like they are defined in two different namespace, it's not a problem. But if you start to import renpy.ast.Show (the ren'py language keyword) in the main namespace, it will overwrite store.Show (the screen action). You'll not know it until you need to use the said screen action, and I'm sure that it will take you a lot of time before you'll figure where's the error ; I'm sure of this because it happen even to way more experienced coder than me.

So, you SHOULD NOT import unless :
You are in your own namespace
OR
Can't access the attribute in another way
OR
Know exactly why you do it
OR
Are sure that there isn't and will never exist an attribute with this name in the actual namespace.

 

[the66]

It's not a caprice, there's a reason behind this. When you import something, you copy it in the module/store where it's imported. So when you write :

    from renpy.persistent import _MutliPersistent

You create a store._MultiPersistent function, which not happen when you use it where it is.

In most of the case it's not a problem because it's a reference-like copy, plus here it's a function, so something intended to be static. But when it's object that you import it increase the number of reference and make the object not disappear when it should, because there's still your copy somewhere.

But the worse case is when it simply and silently overwrite what's already defined (in the console) :

id( Show )
id( renpy.ast.Show )

They are two different objects sharing the same name (there's a lot like this in the core). Like they are defined in two different namespace, it's not a problem. But if you start to import renpy.ast.Show (the ren'py language keyword) in the main namespace, it will overwrite store.Show (the screen action). You'll not know it until you need to use the said screen action, and I'm sure that it will take you a lot of time before you'll figure where's the error ; I'm sure of this because it happen even to way more experienced coder than me.

So, you SHOULD NOT import unless :
You are in your own namespace
OR
Can't access the attribute in another way
OR
Know exactly why you do it
OR
Are sure that there isn't and will never exist an attribute with this name in the actual namespace.

ok, thx for clarifying
..and just to have the last word, good that the import only leads to a reference of an elsewhere declared function
btw the main reason for my orig. post was, making 'MultiPersistent()' useable for android devices and this was achieved