Martijn Faassen wrote:
> I was thinking people would get behind the following proposal:
> IFoo()
> for adaptation and multi adaptation (with tuple arguments)
> and
> IFoo.utility()
> for utility lookups.
> One argument in favor of using plain calls for multi adaptation (using 
> tuples) is that people have already discussed various alternative names 
> to 'adapt' in just this little thread... The other argument is that we 
> would avoid too many ways to do it.

I would love to eventually have IFoo(x,y) be the equivalent of 
getMultiAdapter((x,y), IFoo), but I am -1 on using IFoo((x,y)) for this 
as that would break currently working code. (Not just theoretically, I 
have code in production that does this).

I am +1 on using a __future__+frame hack to get IFoo(x,y) working now, 
but also +1 on using IFoo.adapt(x,y) or IFoo(some_keyword_arg=(x,y)) if 
that is more acceptable.

> Even though I thought we had good consensus on it originally, since then 
> I've seen an argument against a deprecation warning of implicit default 
> on IFoo(). It is a separate discussion. I'd be in favor of it as I think 
> the implicit default argument on IFoo() is not that common (and actually 
> quite hard to read!), but we could easily separate that from this 
> discussion.

+1 on deprecating us of the second positional argument as default, even 
if the signature is otherwise unchanged.

> It would break the backwards compatibility of adapting a tuple using the 
> adapter hook. I think that's a risk we could take.

I disagree, breaking backwards compatibility in this particular way 
would hurt several projects I am involved in.

- Jacob
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to