[PEAK] Interfaces

[Phillip J. Eby]

At 10:53 PM 6/27/2006 -0500, Terry Hancock wrote:
>1) First of all, there's no "verify" methods or functions to check
>    that an object really provides the attributes, methods, and
>    method signatures that its interface declaration says it does.
>
>    This is basically the entire reason for using interfaces as
>    far as I am concerned, so I'm shocked to find this missing.

I'm shocked that you're shocked.  :)

When I need to test an implementation of an interface, I write tests.  For 
example, in RuleDispatch, there's a function called verifyCriterion that 
performs a variety of operational tests on the behavior of an ICriterion 
given to it.


>2) So, I figure I'll need to write that.  But whereas Zope interfaces
>    provide excellent methods for interrogating the interface to
>    see what it expects to be there, I find that there are no such
>    methods on PyProtocols interfaces.  Which means that writing
>    a verifier is oddly difficult.

The dir() function lists all the members of an interface, and the 'inspect' 
module offers plenty of features for inspecting method signatures.  If you 
want exact conformance, just compare the results of inspect.getargspec() 
called on the source and target methods, after removing the "self" argument 
from the target.


>Going back to the PyProtocols documentation, I begin to see
>that adaptation based solely on the assertions in the code seems
>to be the driving idea behind PyProtocols, and it seems to
>ignore other uses of interfaces.

That's correct.  IMO, "consenting adults" means that it's perfectly okay to 
have an error occur when somebody falsely claims support for an 
interface.  EAFP or "easier to ask forgiveness than permission" means 
(among other things) that it's better to catch exceptions than to verify 
trivial preconditions, since Python will detect that the argument signature 
is mismatched (or a method is missing) when it's actually invoked.


>But that leaves a major gaping hole in my QA process. For me,
>one of the most important roles of interfaces is as testing tool
>to make sure that I really do have consistent interfaces between
>objects.  This has been a big time-saver on previous projects.

I'm frankly puzzled by this assertion, since it seems to imply that people 
are declaring that they support interfaces without reading the docs or 
implementing any unit or integration tests to prove it.  It seems to me 
like *that* would be the gaping hole in such a process.

For one thing, I almost always implement an interface's methods by copying 
and pasting from the interface -- which pretty much ensures that the 
signatures are going to be correct.  It's the *semantics* that really need 
testing, and mere interface declaration isn't going to help with 
that.  Whereas if you *have* semantic tests for an interface, signature 
testing is of course an automatic side-effect.


>So, I'm starting to wonder if we're making a mistake by using
>PyProtocols' interfaces.

Probably.  But that's more because interfaces are a mistake in general, 
even PyProtocols' lightweight implementation of the concept.  :)  I've 
pretty much moved on to generic functions, which in addition to being more 
general, also offer more potential (albeit a largely unexplored potential 
at the moment) for semantic verification.  In a generic function, 
declaration and implementation are the same thing -- you can't declare that 
you implement something if you don't, because implementing something is the 
only way to declare it.


>   And if we are, then what *should* we be
>using?  Is there something out there that is a full superset of
>both PyProtocols and Zope interfaces?  Should I be looking at
>Twisted (never touched that as yet)?  Is there something else
>entirely I should be looking at?

It seems to me that what you're looking for is a type checker more than an 
interface system.  At present, zope.interface and PyProtocols are the only 
remaining interface systems for Python.  If your primary interest in 
interfaces is type checking, then you probably want either zope.interface 
or something else.  I think there are a couple of "something elses" out 
there for Python that do runtime type checking of some kind, not counting 
pylint-style source analysis tools.