On Tue, Dec 15, 2009 at 05:32:15PM -0500, Chris McDonough wrote: > I wonder if maybe something like (notionally): > > class InterfaceBase(object): > @classmethod > def add_more_api(cls, **kw): > cls.__dict__.update(kw)
I like this as a clear point to put a pdb when things do not go according to plan. > > > - C > > Leonardo Rochael Almeida wrote: > > Funny you should mention this, I've got this idea bugging for a few > > weeks now, after the last thread: > > > > Have the zope.interface package expose a single overridable hook: > > > > def getInterfaceAttribute(iface, name, default): > > > > This method would be called by any attempt to look up an interface > > attribute that isn't provided by zope.interface itself. For example: > > > > IFoo.adapter(bar, default=baz) > > > > Would be the almost the same as: > > > > getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, > > default=baz) > > > > That is unless getInterfaceAttribute(IFoo, 'adapter') returned the > > passed-in marker which would instruct zope.interface to raise an > > AttributeError instead. > > > > In turn, "zope.component" could then provide a getInterfaceAttribute() > > implementation that called: > > > > getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') > > > > Yes, the first parameter above is the original interface. The > > IInterfaceMethod is an interface defining __call__(*args, **kw) > > > > This idea would also allow one to define named adapters for > > IInterfaceMethod to, for instance, "__call__" or "__add__", such that > > the semantics of "IFoo(...)" or "IFoo + IBar" could also be changed. > > > > Perhaps entry points could be used to provide getInterfaceAttribute > > implementations, and if multiple entry points are present, each would > > be called in turn to attempt to provide the attributes of an > > interface, but maybe this is too much flexibility... > > > > Just an idea... > > > > Cheers, Leo > > > > On Tue, Dec 15, 2009 at 14:16, Thomas Lotze <t...@gocept.com> wrote: > >> So we've decided to let interfaces grow `adapt` and `utility` methods. I've > >> written a simple and straight-forward implementation of them (see the > >> tlotze-component-API branches of zope.interface and zope.component) that is > >> closely modelled on the exisiting `__call__`. In particular, the new > >> methods > >> use component hooks which are like adapter hooks but with a richer set of > >> call > >> parameters. There are a few tests for the new methods as well, so > >> everything > >> should be fine. > >> > >> Except that I don't like the implications now that I have actually written > >> down the code. I'll describe the problem I see and then suggest an idea > >> that I > >> don't think we've been considering in the discussion two weeks ago: > >> > >> We're intentionally leaking the concept of utilities to zope.interface. > >> Assuming we're entirely fine with this, we still need to decide how much of > >> the particulars of the ZCA we want to bring along: named components, lookup > >> contexts, the ComponentLookupError. My current implementation tries to > >> introduce enough generic behaviour into the `adapt` and `utility` methods > >> so > >> that they don't cause too obvious (conceptual) dependencies of > >> zope.interface > >> on zope.component: > >> > >> * `adapt` and `utility` don't define particular optional arguments but pass > >> all keyword parameters except for `default` to the component hook which, > >> being implemented by zope.component, keeps the knowledge about named > >> adapters and lookup contexts within the latter package. > >> > >> * The hook invokes the `query*` functions to play nice with any other > >> component hooks and the interface methods raise a TypeError if all of them > >> fail to find a component. > >> > >> However, the generic behaviour gets in our way: the method signatures > >> become > >> useless and hooks lose the possibility of raising useful exceptions. > >> > >> I've tried some variations but as long as the `adapt` and `utility` methods > >> are actually implemented by zope.interface, it will always come down to a > >> compromise that either renders the new methods unusable with anything > >> that's > >> not very much like zope.component, or makes for a half-hearted copy of the > >> functionality we currently have in the zope.component API. > >> > >> I discussed this a bit with Wolfgang as we both don't like this kind of > >> compromise in such core functionality. We came up with the idea that a > >> clean > >> solution would be to keep any implementation of the two methods out of > >> zope.interface and rather inject them into the interface API by code kept > >> entirely within zope.component. We do realise how close to the concept of > >> monkey-patching this comes, but maybe it wouldn't be so bad if we could do > >> it > >> in a more structured way (being intentionally vague here yet). > >> > >> In particular, keeping the concrete `adapt` and `utility` methods out of > >> the > >> core implementation of interfaces would address the concern raised by > >> somebody > >> on this list that we were going to tailor zope.interface too much to the > >> needs > >> of the Zope ecosystem. Uses of interfaces other than adaptation and > >> component > >> lookup could get convenience methods registered by the same mechanism > >> zope.component would end up employing, which is a big conceptual advantage > >> from my point of view. > >> > >> What do people think of this? > >> > >> -- > >> Thomas > >> > >> > >> > >> _______________________________________________ > >> Zope-Dev maillist - Zope-Dev@zope.org > >> 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 ) > >> > > _______________________________________________ > > Zope-Dev maillist - Zope-Dev@zope.org > > 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 ) > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > 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@zope.org 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 )
