Martijn Faassen wrote:
> Simple adaptation:
Is there an implied default of None here or would a ComponentLookupError
> Named adaptation:
> IFoo(adapted, name="foo")
> Adaptation with a default
> IFoo(adapted, default=bar)
> IFoo(one, two)
> Named multi adaptation:
> IFoo(one, two, name="foo")
> Multi-adaptation with a default:
> IFoo(one, two, default=bar)
> Utility lookup:
> Named utility lookup:
> Utility lookup with a default:
> Where "name" and "default" can be combined. The name and default keyword
> parameters have to be used explicitly - *args is interpreted as what to
> adapt only. Any other keyword parameters should be rejected.
*like* all of the above +sys.maxint :-)
> We could introduce the following upgrade pattern:
> zope.component 3.8.0: old semantics
> zope.component 3.9: old semantics is the default. new semantics
> supported too somehow but explicitly triggered.
> zope.component 4.0: new semantics is the default. Old semantics is not
> supported anymore.
I'd propose just having:
3.x -> old semantics
4.x -> new semantics
> We could, if needed, maintain zope.component 3.x in parallel with the
> new-semantics 4.0 line for a while.
3.x should just drop into "bugfix only" mode, which it already is, and
can be maintained as long as people are interested in maintaining it.
> A per-module triggering of the new semantics might be done like this:
> from zope.component.__future__ import __new_lookup__
> Is that implementable at all however? Someone needs to experiment.
If it is, that would be great, otherwise I'd prefer it just to be clear
and simple as I suggested. I wish there was a setuptools-ish way to say
"if a package doesn't explicitly require zope.component >= 4.0, then
barf if we're installed". I'll enquire on distutils-sig...
> Alternatively we could do something special when we see this: IFoo(foo,
> bar). This is ambiguous
Is this the only ambiguous case?
>- is the new semantics in use or the old one? If
> the adapter cannot be looked up using multi adaptation we *could* fall
> back on single adaptation under the assumption that the old semantics
> are desired. But this will lead to a problem if the new semantics *was*
> desired but the component simply could not be found.
Yeah, DWIM is mad and bad, please lets not do that...
> I think it's important not to do a "big bang" upgrade but instead allow
> people to upgrade bit by bit. It should be possible to compose an
> application that mixes code that expects the old semantics with code
> that expects the new semantics. A bit by bit upgrade I think would
> ideally be on a per-module basis. I think it's important to make sure we
> can support such an upgrade *before* we release any of this.
This paragraph is a big ask, too big in my opinion...
Simplistix - Content Management, Batch Processing & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -