Thomas Lotze wrote:
> Martijn Faassen wrote:
>> * have dummy implementations in zope.interface that raise
> 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.
I think having these markers is very important for code readability.
People reading the code will otherwise have no idea whatsoever where
these methods come from.
I'm not sure whether much of a general mechanism is really needed, after
all we already have monkey patching (um, sorry Tres, modifying a class).
I can see there being an API in zope.interface that allows one to plug
into .utility() and .adapt()
>> * have that NotImplementedError say to look for implementations in
> 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)?
I think it will be less clear compared to the methods being there and
saying they're injection points intended to be overwritten.
>> 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.
Let's deprecate 'alternate' and introduce 'default' then. Might actually
make the deprecation more easy..
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -