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

On Mon, Apr 9, 2012 at 4:33 PM, Tres Seaver <[email protected]> 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 <[email protected]>
>> 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  -  [email protected]
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 )