A few points instead of a point by point reply.
* I thought we had agreed to add methods to Interface that support multi
adapter and utility lookup. We seem to have, but only about the external
API, not about where the implementation is. (even if in my plugin
proposal the implementation still lies in zope.component)
* Apparently not even single adapter lookup is supported by you, at
least as implemented in zope.interface. I had not previously realized
that the current implementation of __call__ could be considered wrong by
* You appear to be looking for something that at least in the Python
language is only accepted as a kind of hack: an ability to extend the
API of an existing class far away from the definition of that class,
without there being a subclassing relationship (or I suppose, a class
decorator). The idea in Python is generally that the API of a class is
defined by that class or its base classes, not elsewhere.
* There is of course a way to extend what one can do with an object in
Python. Subclassing is one way, adaptation another, and defining
functions another. The last is what zope.component does.
* I do not know of a user community that uses zope.interface and does
not use a component architecture. The Twisted community for instance
uses zope.interface's adapter registry and __call__ hook. This is an
argument for making component lookup an integral part of
zope.interface's responsibilities. I think you could even make an
argument for folding zope.component's responsibilities into
zope.interface, though I'm not currently proposing this (also because
we're are looking to improve the implementation, see below).
Generalizing what kinds of component lookups one can do using Interface
seems like a good idea from this perspective.
* I think it is entirely possible that people will plug in alternative
component lookup strategies to zope.interface in the future, as the long
discussion also involved changing the way zope.component's internals worked.
* All this questioning of fundamentals makes me inclined to give up on
this project for the time being. I thought we had reached a conclusion,
but I was wrong. Too many cooks?
Some more technical points:
* you wonder about a 'context' parameter. Are you talking about the
lookup context here? We hadn't considered passing through the lookup
context in previous discussions. We could leave that out for the time being.
* A single plugin seems fine instead of a list of plugin points for
zope.interface. I think a single plugin, using a global would be the
most straightforward and readable solution, but perhaps some performance
measurements would be interesting.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -