[Zope-dev] Adding broken/missing support to zope.interface?

[Ross Patterson]

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?  If so, what's
the right way to approach implement that?  Just monkey patching from
ZODB to zope.interface?

Ross