Phillip J. Eby
pje at telecommunity.com
Wed Jun 28 07:46:22 EDT 2006
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
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.
More information about the PEAK