[ZODB-Dev] Re: [Zope3-dev] Re: Persistent module notes and proposal
jim at zope.com
Thu Jan 8 06:08:48 EST 2004
Tres Seaver wrote:
> Leonardo Rochael Almeida wrote:
>> At Mon, 05 Jan 2004 18:09:16 -0500, Jim Fulton wrote:
>>> Casey Duncan wrote:
>>>> On Mon, 05 Jan 2004 16:36:24 -0500
>>>> Jim Fulton <jim at zope.com> wrote:
>>>>> 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.
>>>> I agree. So classes and functions in persistent modules are persistent
>>> Yes. There's a mapping step that happens after module execution in
>>> which we map regular classes, functions, and interfaces to persistent
>>> ones, updating existing values as appropriate to make imported refernces
>>> do the right thing.
>> What if we do it the other way around, and treat module globals as
>> explicitly volatile?
>> PM globals wouldn't survive a server restart nor a PM edit, as editing
>> module would imply a module reload.
>> I think this matches more closely the behaviour of fs modules, which we
>> are already used to. This might make PMs less useful, but their semantic
>> will be more easily defined and their implementation a little bit easier,
>> I think. This achieves the goal of reflecting the module state solely by
>> their source, and even allows PM global mutables to be used for volatile
>> registries, just like fs modules.
> +1, as you have just expressed the notion which has been struggling to
> the surface of my mind as I have mulled over this thres. I think the
> *only* persistent attribute of the PM should be the source itself; all
> else would a "cooked" cache.
> This is somewhat like the "PythonLibrary" notion which Evan Simpson has
> been kicking around for Python2.
But PythonLibrary doesn't aim to be like a module. It doesn't try to support
import. It doesn't ain to support instances of persistent classes. (It probably
doesn't aim to support classes at all.)
Persistent modules *do* support import. You could have:
from M1 import X
from persistence import Persistent
class Y(X, Persistent):
Now, if someone changes X in M1, we need Y to reflect the change.
Likewise, if we have instances of Y, we expect those instances to
reflect changes to X or Y.
To do this, we need to be able to update objects perviously defined
by a module. I'll note that this works now (in ZODB 4).
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