Mailing List Archive: Zope: Dev

Re: Adding broken/missing support to zope.interface?

Index | Next | Previous | View Threaded

tseaver at palladion

Apr 9, 2012, 1:33 PM

Post #1 of 5 (238 views)
Permalink

Re: Adding broken/missing support to zope.interface?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/09/2012 04:15 PM, Martin Aspeli wrote:
> On 9 April 2012 15:41, Brian Sutherland <brian [at] vanguardistas>
> wrote:
>
>> On Sun, Apr 08, 2012 at 01:04:37PM -0700, Ross Patterson wrote:
>>> experimental.broken is working well for me. It greatly aided me
>>> in getting through a particularly nasty upgrade allowing me to
>>> cleanup the ZCA cruft left by poorly behaved add-ons. I'd like
>>> to proceed with adding the core of this to zope.interface and I
>>> need the developers/maintainers to weigh in.
>>>
>>> The first and most fundamental matter is changing interface
>>> pickles such that they can be unpickled into something that can
>>> fulfill the minimum interface contract and don't break the ZCA. To
>>> that end, I'd like to add the following to
>>> zope.interface.interface:
>>>
>>> ... try: from ZODB.broken import find_global from ZODB.broken
>>> import IBroken def find_interface(modulename, globalname,
>>> Broken=IBroken, type=InterfaceClass): """ Find a global
>>> interface, returning a broken interface if it
>> can't be found.
>>> """ return find_global(modulename, globalname, Broken=IBroken,
>>> type=InterfaceClass) except ImportError: IBroken = Interface def
>>> find_interface(modulename, globalname, Broken=IBroken,
>>> type=InterfaceClass): """ Find a global interface, raising
>>> ImportError if it can't be
>> found.
>>> """ # From pickle.Unpickler.find_class __import__(module) mod =
>>> sys.modules[module] klass = getattr(mod, name) return klass ...
>>> class InterfaceClass(Element, InterfaceBase, Specification): ...
>>> def __reduce__(self): if self is IBroken: return self.__name__
>>> return (find_interface, (modulename, globalname)) ...
>>
>> -1

Agreeed. I'm more like -20 on this implementation, but +1 on the goal.

>>
>> For a number of reasons, but mainly because you add a test
>> dependency on the ZODB from zope.interface. I think that
>> zope.interface is such a fundamental package and the dependency is
>> unacceptable.
>>
>
> It's a soft dependency only, looking at the code sample.
>
>
>> There has lately been a LOT of work done reducing the dependency
>> structure of zope.* packages. You need a VERY good reason to start
>> reversing that.
>
>
> It doesn't add any more (required) dependencies.

- -1 on any dependency, soft or hard, from zope.interface -> ZODB

> This is a real issue that is breaking the sites of a lot of real
> users of zope.interface in a way that is hard to debug and reverse.
>
> Can you think of a better way to get around it? Other than "don't get
> into the situation" which isn't a valid answer as long as the ZTK
> ecosystem supports persistent local components.

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.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+DR4gACgkQ+gerLs4ltQ5THACgzvZtoksPW/V30TsR3pWa7PyY
WUwAniRY51tIHXS1ohd/6K+TkZZwy+7A
=kdaO
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

jim at zope

Apr 9, 2012, 1:45 PM

Post #2 of 5 (231 views)
Permalink

Re: Adding broken/missing support to zope.interface? [In reply to]

On Mon, Apr 9, 2012 at 4:33 PM, Tres Seaver <tseaver [at] palladion> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/09/2012 04:15 PM, Martin Aspeli wrote:
>> On 9 April 2012 15:41, Brian Sutherland <brian [at] vanguardistas>
>> wrote:
>>
>>> On Sun, Apr 08, 2012 at 01:04:37PM -0700, Ross Patterson wrote:
>>>> experimental.broken is working well for me. It greatly aided me
>>>> in getting through a particularly nasty upgrade allowing me to
>>>> cleanup the ZCA cruft left by poorly behaved add-ons. I'd like
>>>> to proceed with adding the core of this to zope.interface and I
>>>> need the developers/maintainers to weigh in.
>>>>
>>>> The first and most fundamental matter is changing interface
>>>> pickles such that they can be unpickled into something that can
>>>> fulfill the minimum interface contract and don't break the ZCA. To
>>>> that end, I'd like to add the following to
>>>> zope.interface.interface:
>>>>
>>>> ... try: from ZODB.broken import find_global from ZODB.broken
>>>> import IBroken def find_interface(modulename, globalname,
>>>> Broken=IBroken, type=InterfaceClass): """ Find a global
>>>> interface, returning a broken interface if it
>>> can't be found.
>>>> """ return find_global(modulename, globalname, Broken=IBroken,
>>>> type=InterfaceClass) except ImportError: IBroken = Interface def
>>>> find_interface(modulename, globalname, Broken=IBroken,
>>>> type=InterfaceClass): """ Find a global interface, raising
>>>> ImportError if it can't be
>>> found.
>>>> """ # From pickle.Unpickler.find_class __import__(module) mod =
>>>> sys.modules[module] klass = getattr(mod, name) return klass ...
>>>> class InterfaceClass(Element, InterfaceBase, Specification): ...
>>>> def __reduce__(self): if self is IBroken: return self.__name__
>>>> return (find_interface, (modulename, globalname)) ...
>>>
>>> -1
>
> Agreeed. I'm more like -20 on this implementation, but +1 on the goal.
>
>>>
>>> For a number of reasons, but mainly because you add a test
>>> dependency on the ZODB from zope.interface. I think that
>>> zope.interface is such a fundamental package and the dependency is
>>> unacceptable.
>>>
>>
>> It's a soft dependency only, looking at the code sample.
>>
>>
>>> There has lately been a LOT of work done reducing the dependency
>>> structure of zope.* packages. You need a VERY good reason to start
>>> reversing that.
>>
>>
>> It doesn't add any more (required) dependencies.
>
> - -1 on any dependency, soft or hard, from zope.interface -> ZODB
>
>> This is a real issue that is breaking the sites of a lot of real
>> users of zope.interface in a way that is hard to debug and reverse.
>>
>> Can you think of a better way to get around it? Other than "don't get
>> into the situation" which isn't a valid answer as long as the ZTK
>> ecosystem supports persistent local components.
>
> 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.

+1

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://www.dublinstore.com/
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

hanno at hannosch

Apr 9, 2012, 2:54 PM

Post #3 of 5 (226 views)
Permalink

Re: Adding broken/missing support to zope.interface? [In reply to]

On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tseaver [at] palladion> 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.

Hanno
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

me at rpatterson

Apr 11, 2012, 9:30 AM

Post #4 of 5 (215 views)
Permalink

Re: Adding broken/missing support to zope.interface? [In reply to]

Hanno Schlichting <hanno [at] hannosch> writes:

> On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tseaver [at] palladion> 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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 at vanguardistas

Apr 11, 2012, 10:28 AM

Post #5 of 5 (219 views)
Permalink

Re: Adding broken/missing support to zope.interface? [In reply to]

On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote:
> Hanno Schlichting <hanno [at] hannosch> writes:
>
> > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver <tseaver [at] palladion> 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
> 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 [at] zope
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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads