On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote: > Hanno Schlichting <ha...@hannosch.eu> writes: > > > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tsea...@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 _______________________________________________ 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 )