For my 2 cents (not that I think anyone should care):

+1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw)

-1 for tuple adaptation on 1st arg. Besides losing genericity on tuple
adaptation, we risk situations where a class could trigger
multi-adaptation by inheriting from tuple.

+1 for deprecating unamed "default" argument. Yes, this is separate
from the 1st item above but if in the future we want to expand/fix the
IFoo() semantics, we should start deprecating things as early as
possible. Besides "defalt=something" is way more readable and
explicitly, especially when you consider the "typecasting" mindset.

Cheers, Leo

On Thu, Dec 3, 2009 at 10:00, Martijn Faassen <> wrote:
> Gary Poster wrote:
>> I think I could get fully behind the following proposal that others
>> have made (Shane I think was one of several?).
>> IFoo.adapt(...)
>> IFoo.utility(...)
> 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.
> 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.
> It would break the backwards compatibility of adapting a tuple using the
> adapter hook. I think that's a risk we could take.
> Regards,
> Martijn
> _______________________________________________
> Zope-Dev maillist  -
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to