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 - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
