-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Thomas Lotze wrote:
Martijn Faassen wrote:
* 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.
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()
I don't see any win for the "generic" extensions either: we already know *exactly* what two methods we want to use, and have no use cases at all for adding any others.
* 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)?
I think it will be less clear compared to the methods being there and saying they're injection points intended to be overwritten.
- -1 to any docstring / exception method which points outside the zope.itnerface package. There is a perfectly reasonable "default" implementation anyway (in the absence of any hooks): - - IFoo.adapt(context) raises LookupError, unless the context provides IFoo, in which case it returns context. - - IFoo.adapt(context, default=default) returns default unless context provides IFoo, in which case it returns context. - - IFoo.utility() raises LookupError. - - IFoo.utility(default=default) returns default I would much rather keep a "hook registration" API in the interface class for these methods than obscure their origin semantics via a monkey patch.
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..
Note that Interface.__call__ is not documented at all as an API:: $ grep __call__ src/zope/interface/interfaces.py $ I think we should just rename the argument without any deprecation. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspVZYACgkQ+gerLs4ltQ52fACcC3Pd8uGvTzjkKwmTX97PrQaf oxkAoLoA1lRxpPA6HpQYQtifxQBM8sbF =jebA -----END PGP SIGNATURE-----