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