I wonder if maybe something like (notionally):
def add_more_api(cls, **kw):
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
>> 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
>> 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
>> on this list that we were going to tailor zope.interface too much to the
>> 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?
>> Zope-Dev maillist - Zope-Dev@zope.org
>> ** No cross posts or HTML encoding! **
>> (Related lists -
>> https://mail.zope.org/mailman/listinfo/zope )
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -