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.
On Thu, Dec 3, 2009 at 10:00, Martijn Faassen <faas...@startifact.com> 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?).
> I was thinking people would get behind the following proposal:
> for adaptation and multi adaptation (with tuple arguments)
> 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
> It would break the backwards compatibility of adapting a tuple using the
> adapter hook. I think that's a risk we could take.
> Zope-Dev maillist - zope-...@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 -