Re: Re: reasonable syntax for multi-adaptation

On Sep 28, 2007, at 10:31 AM, Martijn Faassen wrote:

> Dominik Huber wrote:
>> It would be great, if we could handle other adaption-derivations  
>> by the proposed unified, reasonable adaption-api too.
> [snip interesting proposal]
>
> Okay, so there seems to be quite a bit of consensus for *some* form  
> of support for this. I've seen a number of proposals which to me  
> look quite reasonable.
>
> Since Jim doesn't like this much but there seems to be a lot of  
> support from others,

And am willing, therefore, to compromise

> we could investigate whether we can't come up with something that:
>
> * doesn't break the existing notation. The cleanest way to support  
> such non-interference seems to be to do this using an extra .adapt  
> method. This is unfortunate, as I at least consider it prettier if  
> it used the IFoo() syntax (even though I proposed .adapt).

I agree.

>
> * creates a small a new hook inside zope.interface to support this

After thinking about it, I think I can avoid the extra hook.  Don't  
worry about the details. :)

>
> * can be plugged in by an optional extension, like  
> zope.interfacextended

See above.

> * implements the proposed new features. I like the idea of also  
> allowing utility lookup through the same mechanism.

I don't, but I'm willing to give in to popular demand.

BTW, we *could* use interface __call__ for utility lookup, as there  
would be no conflict with current notation *if* we specified a  
default using a keyword argument.
I would far prefer using

   IFoo() or IFoo(default=None)

to look up a utility over:

   IFoo.adapt() or IFoo.adapt(default=None)

for, I hope, obvious reasons.

I'd also like to support specifying a default for adapter lookup via  
a keyword argument.  In fact, I'd like to deprecate passing the  
default positionally.  This would open the door, sometime in the  
future, to allowing multi-adaptation via: IFoo(ob1, ob2).

> So, any volunteers to try to implement this?

I insist on reviewing any change before checking it in.  This will  
create an unavoidable bottle neck.

Jim

--
Jim Fulton
Zope Corporation