Thinking a little about latent interfaces (and latent typing, but mostly the interfaces) -- one of the issues with an interface in Python (or this Smalltalk implementation that someone noted in a comment) is that they consist of method signatures, but nothing about semantics. This is even more true with latent interfaces (where latent interfaces are the interfaces you can infer from how code uses an object).
The way to make latent interfaces safer in a dynamic environment is generally to choose good method names -- you shouldn't use the same method name for two conceptually different operations. The example in the comments to Bruce's post is a method shoot() that may refer to a Gun or Camera, where each has very different semantic meaning.
A more practical example might be obj.write(value) which might mean write value to obj (i.e., a file-like object), or write obj to value (i.e., serialize obj). That's a bad choice of method names, because they mean very different things, but if you accidentally get an object that uses the latter semantics where the first are expected, you could get very weird behavior.
An explicit interface usually implies specific semantics -- that's why it's okay to have two interfaces which programmatically look the same, i.e., define the same set of method names and signatures. Usually an interface also includes documentation which provides a description of the semantics.
Unfortunately, this doesn't offer any program-accessible semantics, only programmer-accessible. We can programmatically check signatures, but how can we check semantics? Statically typed languages are a little better on this, because their signatures include type information which starts to define semantic relationships.
Anyway, we still have something more general than static typing in contracts -- or more concretely, pre- and post-conditions (typically a bunch of asserts). After all, what's a type declaration besides an assertion of type? (Well, asserted at compile-time instead of runtime, but eh)
A neat extension to an interface system (like PyProtocols) would be to add contracts. The contracts would be attached to the interfaces themselves, not the particular implementation of those interfaces.
To do this you'd have to change the adapt() function to return a wrapper -- this wrapper would intercept calls that had interface contracts, and confirm the contract as well as delegating to the original code. (There might be other ways -- PEP 246 describes the lower-level mechanics of adaptation)
You don't need to add any functionality at all to PyProtocols, all of this is already there. It's up to the object, the protocol (interface), or some adapter to decide what kind of object gets returned (or doesn't). If you want this proxying style, you simply make either the objects, the protocols, or adapters return these proxies. So the answer is yes, you would have to write code, but no, you don't have to change what PyProtocols does.
Then I guess you'd have to change your... interface objects? Using the improved Interface class as the superclass for all your interfaces...? Ideally you shouldn't need to make any changes to the objects that implement the interfaces in order to support contracts, only to the interfaces themselves.# Ian Bicking
You don't need to change anything, you just implement some interface object that is compliant with PyProtocols (i.e. a subclass of Interface) and use that whenever you want its special behavior.
For contracts in python, check out http://www.logilab.org/projects/aspects which brings Aspect-Oriented Programming to python and implements Contracts as an Aspect.