Martijn Faassen wrote: >> * The hook invokes the `query*` functions to play nice with any other >> component hooks and the interface methods raise a TypeError if all of >> them fail to find a component. > > A TypeError instead of a ComponentLookupError? > > I was thinking we should keep the behavior as close to zope.component as > we can, including ComponentLookupError. Don't you get a > ComponentLookupError with the classic adapter hook too? So I'm -1 to > making this a TypeError.
The ComponentLookupError is defined by zope.component. So the only way of getting a CLE raised by Interface.adapt or Interface.utility would be to call the non-query-style lookup functions from the zope.component API and let the error propagate. The current implementation of the new interface methods pretend, however, to allow for more hookability than just calling a zope.component function, so it is intentional to not let any error propagate but defer to the next hook instead and raise an exception of a type known to zope.interface (i.e. not CLE) if none of the hooks succeeds. The choice of TypeError was made in analogy with __call__. Currently, you get a TypeError if IFoo(bar) fails while zope.component.getAdapter(bar, IFoo) raises CLE. IMO, the clean way to solve this is to drop the analogy with the __call__ implementation and no longer try to cater for generic `adapt` and `utility` behaviour. Together with avoiding a direct dependency of zope.interface on zope.component, this leads to injecting non-hookable implementations of `adapt` and `utility` from zope.component itself. > I think a monkey patch would be fine. Opinions about making it more > structured: > > * have dummy implementations in zope.interface that raise > NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. > * have that NotImplementedError say to look for implementations in > zope.component I would actually like a mechanism that doesn't care about what package will inject which pieces of API. Do you think such generality is asking too much (at least at this point in time)? > * have the docstring on the methods that are injected be clear that they > are being injected into zope.interface Of course. > That way someone reading the zope.interface code can at least find out > that this functionality is injected from zope.component. IMO, we should mention this as a usage example but not as a requirement. > [as an aside it'd be interesting to find out how much of of zope.component > functionality could sensibly make it into zope.interface, but that's > another project; Gary Poster has some ideas in relation to this] I think before doing such a thing, we should come up with a precise definition of which concepts are the concern of interfaces, which are that of the ZCA and exactly where to draw the line. Anything else looks IMO dangerously like a slippery slope towards mixing it all up into zope.interface. > I'm still sneakily hoping that in a few years we'll be able to get calling > the interface be the one true way of looking up implementations of that > interface (utilities and adapters and whatnots), but we'll see. Me too. > Did you make an implicit 'default' deprecated on __call__ yet by the way? Not yet; the other issue looked more interesting so far ;o) BTW, that parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. -- Thomas _______________________________________________ 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 )