Marius Gedminas wrote:
> So I'm -99 for magical side effects of import statements, but thankfully
> the community opinion is already against them.
Yeah, I was a bit too cavalier in earlier discussions about such a
solution. Tres suggested having a proper plugin API for this and a
registration function, and I agree. This should be called early in the
startup sequence but not during import time.
> I'm -0 for having an implementation that seems to be working, but
> isn't (utility lookup when no utilities can possibly be defined? very
> useful, that), unless you invoke some magical incantation.
> It's only -0 rather than something stronger because the same sort of
> situation already exists with Interface.__call__ hook, and it doesn't
> cause any problems in practice (probably because everybody calls
> placelessSetUp() at the start of their test setUp).
I see this as a bootstrapping issue as we're fiddling with the component
Normally when I want to provide a plugin API for a library I'd look into
using adapters or utilities. The library would look these up, and
external systems have to provide them. If they don't, it won't work
(ComponentLookupError) or alternatively the library falls back on
default behavior. Such a design pattern I dare say is fairly accepted
within the user community of the ZCA. :)
But since we are bootstrapping the component architecture itself, we
have to come up with an alternative implementation. We instead offer a
registration API in zope.interface and we have zope.component register
the appropriate plugin.
We then modify the startup procedure to tell zope.component to register
itself with zope.interface, and we modify the testing infrastructure
provided by zope.component to do the same thing. As you say something
very similar is going on with the traditional adapter hook already.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -