Hash: SHA1

On 04/09/2012 04:15 PM, Martin Aspeli wrote:
> On 9 April 2012 15:41, Brian Sutherland <br...@vanguardistas.net> 
> 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 Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to