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 )

Reply via email to