[Zope-dev] Adding broken/missing support to zope.interface?
Brian Sutherland
brian at vanguardistas.net
Wed Apr 11 17:28:17 UTC 2012
On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote:
> Hanno Schlichting <hanno at hannosch.eu> writes:
>
> > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tseaver at 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 at 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
More information about the Zope-Dev
mailing list