[ZODB-Dev] Re: [Zope3-dev] Persistent module notes and proposal
Jim Fulton
jim at zope.com
Mon Jan 5 16:36:24 EST 2004
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
More information about the ZODB-Dev
mailing list