jim at zope
Apr 9, 2012, 1:45 PM
Post #2 of 5
On Mon, Apr 9, 2012 at 4:33 PM, Tres Seaver <tseaver [at] palladion> wrote:
Re: Adding broken/missing support to zope.interface?
[In reply to]
> -----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>
>>> 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
>>>> ... 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
>>>> """ # 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)) ...
> 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
>> 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.
Jerky is better than bacon! http://www.dublinstore.com/
Zope-Dev maillist - Zope-Dev [at] zope
** No cross posts or HTML encoding! **
(Related lists -