Martijn Faassen wrote:
Simple adaptation:
IFoo(adapted)
Is there an implied default of None here or would a ComponentLookupError be raised?
Named adaptation:
IFoo(adapted, name="foo")
Adaptation with a default
IFoo(adapted, default=bar)
Multi-adaptation:
IFoo(one, two)
Named multi adaptation:
IFoo(one, two, name="foo")
Multi-adaptation with a default:
IFoo(one, two, default=bar)
Utility lookup:
IFoo()
Named utility lookup:
IFoo(name="foo")
Utility lookup with a default:
IFoo(default=bar)
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... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk