On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote:
Hanno Schlichting <hanno@hannosch.eu> writes:
On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tseaver@palladion.com> wrote:
Persistent component registries are not a good enough reason to add such coupling (I'd be in favor of splitting support for persistent registries out of zope.component, too, while we're at it).
Let's put the "broken" support into code which depends on zope.interface, zope.component, and the ZODB, and invert the dependency by having the new code install something into the base code which provides the desired support: the only change to zope.interface should be documenting the insertion point, and testing that it does the right thing when a dummy is plugged into it.
I looked at the possible contenders for that dependency description. The ZODB depends on zope.interface itself, though not on zope.component.
zope.container is the one that has the most minimal dependencies, while still relying on zope.component and the ZODB.
zope.site depends on zope.container, but given its scope sounds like the better place to me. I vaguely remember us discussing to move persistent registries into zope.site at some point. Since we moved zope.site.hooks into zope.component, zope.site doesn't have much else to do anymore.
Apart from those two, there's a whole lot more that have far more dependencies or are unrelated in scope, like zope.annotation or zope.catalog.
This problem isn't so much ZODB specific as it is specific to pickling. The problem I don't know how to solve without modifying zope.interface is that the on pickle end of things, the only hook I'm aware of is on the unpickling side, namely overriding `find_global` as ZODB does. But there's no way for `find_global` to know that the given global should be an interface just from the module and name which is what the pickle contains. We need to hook into the process at the time the object is pickled. As far as I can see the only way to do that is through the object's __reduce__ method.
As such, the only options I see are to add something conditional to `zope.interface.InterfaceClass.__reduce__` or to make `zope.interface.InterfaceClass.__reduce__` hookable in some way. Would the latter address the concerns people are raising here?
Tres was suggesting something like that. It would address my concerns.
If so, what's the right way to approach implement that?
I think you need someone intimate with the ZODB to suggest that. One way might be something like the adapter_hooks already present in interface.py. That would at least be consistent, but there are probably many good reasons to not do it that way. That code could look something like: reduce_hooks = [] class InterfaceClass: def __reduce__(self): for hook in reduce_hooks: result = hook(self) if result is not None: return result return self.__name__
Just monkey patching from ZODB to zope.interface?
Indeed, that is also another option.
Ross
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland