[Zope3-dev] Persistent module notes and proposal

[Casey Duncan]

On Mon, 05 Jan 2004 14:35:43 -0500
Jim Fulton <jim at zope.com> wrote:

> Casey Duncan wrote:
> > On Mon, 05 Jan 2004 13:57:38 -0500
> > Jim Fulton <jim at zope.com> wrote:
[...]
> > Perhaps changes to persistent modules, like filesystem modules
> > should not take
>  > effect until the application is restarted, or unless an explicit
>  > "refresh" operation is performed on the server.
> 
> That would cause you to lose a significant benefit of persistent
> modules. In any case, how would that help?
> 
>  > If that isn't the case then how do you deal with other modules that
>  > have imported from the persistent module?
> 
> What do you mean? What's to take care of?

If I have the following in a module named "bar":

foo = [1,2,3]

and in a module named splat I do:

from bar import foo

Then I change the source of bar to:

foo = [0,1,2,3]

Does the value of "foo" imported in splat also change and when (Next
transaction, etc)?

[...]
> > If the state of a persistent module is itself persistent, then the
> > problem is broader IMO since the semantics are considerably
> > different from filesystem modules.
> 
> Yes, except that here, you should realize that we have a sort of a
> persistent application whos execution spans many physical process
> executions.

Yes, so a persistent module's state spans multiple Python processes (in
parallel when ZEO is in play). Oh boy.

>  > On those grounds I would argue that persistence of module state
>  > would be a misfeature since it's  volatile in potentially
>  > surprising ways.
> 
> This doesn't make sense to me. In what sense if it volatile?

It's volatile when you change the module, but not when you restart which
is surprising (to me). Not because it doesn't make sense in context, but
because you think "Oh its just a module", but its really a pretty
different beast at heart.

> > That sheds some more light, however the problem would still exist
> > for TTW editing AFAICT.
> 
> True, if you edit the module, you reexecute it's source, and,
> depending on the source, changes not reflected in the source would be
> lost.
> 
> All the more reason why I think that persistent modules should be
> limited to containing only software (i.e. classes, functions,
> interfaces, and static data).

I continue to agree. So we either need to make it impossible to mutate
module state (seems unlikely) or somehow make it clear that it is not a
supported use or do nothing and expect many people to naively do the
wrong thing and let them lose.

-Casey