[ZODB-Dev] Re: [Zope3-dev] Persistent module notes and proposal

[Jim Fulton]

Casey Duncan wrote:
> 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)?


No. Don't do that. :)

If you wanted to share a list that way, you'd need to make
it a persistent list.

I'm inclined to disallow import of non-persistent objects
from persistent modules.

> [...]
> 
>>>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.

Yup.

> 
>> > 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.

It's a persistent module.  :)

>>>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.

Yup.  A possibility is to really only allow a few types (e.g. interfaces,
classes, functions, tuples, strings, etc.)

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org