Marius Gedminas wrote:
What's the motivation?
The "utilities must be singletons" logic hardcoded in the ZCA.
provideAdapter(factory, adapts=(one, two, three)) provideAdapter(factory, adapts=(one, two)) provideAdapter(factory, adapts=(one, ))
The natural progression, to me, is
provideAdapter(factory, adapts=())
Makes perfect sense to me :-)
rather than
provideUtility(singleton)
If we decide, ignoring BBB concerns, to make
provideUtility(singleton, provides=IFoo)
be equivalent to
provideAdapter(lambda: singleton, adapts=(), provides=IFoo)
Also makes perfect sense to me, also seems like a reasonable implementation for provideUtility :-)
This also assumes that I'm free to
provideAdapter(arbitrary_callable, adapts=())
and use computed-utility-lookup, or even create utilities on demand in my arbitrary_callable.
I can't see why you wouldn't be able to, adapters are just callables afterall... Would suggest some docs to cover the gotcha though: class CreateFrobsUtility: def __call__(self): return Frob() Bug: provideAdapter(CreateFrobsUtility, provides=IFrobFactory) Correct: frobsmaker = CreateFrobsUtility() provideAdapter(lambda:frobsmaker, provides=IFrobFactory) Having provideUtility around is a good thing to save typing :-)
Three cheers for utility and empty-tuple-adapter unification!
Indeed!
Ignoring BBB and assuming utilities are distinct fowl,
They aren't ;-)
The phrasing of your question ("deprecate") makes ignoring BBB impossible, in which case I'd prefer to have a 100% backwards-compatible IFoo(single_arg, [default]) + IFoo.adapt(*args, **kw) + IFoo.utility(**kw).
How do you feel about: - introducing .get(*to_adapt,default=marker,name=None) ASAP - switching the semantics of IWhatever() in 4.0 ? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk