Programming by Contract

[Charles Yeomans]

On Aug 11, 2009, at 3:30 PM, Ethan Furman wrote:

> Ethan Furman wrote:
>> Greetings!
>> I have seen posts about the assert statement and PbC (or maybe it  
>> was DbC), and I just took a very brief look at pycontract (http://www.wayforward.net/pycontract/ 
>> ) and now I have at least one question:  Is this basically another  
>> way of thinking about unit testing, or is the idea of PbC more  
>> along the lines of *always* checking the input/output of functions  
>> to ensure they are correct?  (*Contstant vigilance!* as Prof Moody  
>> would say ;)
>> I know asserts can be turned off, so they obviously won't work for  
>> the latter case, and having seen the sample of pycontract it seems  
>> it only does its thing during debugging.
>> So is Design (Programming) by Contract a fancy way of saying  
>> "Document your inputs/outputs!" or is there more to it?
>> ~Ethan~
>
> Hmmm...
>
> Well, from the (apparently) complete lack of interest, I shall take  
> away the (better?) documentation ideas and unit testing ideas, and  
> not worry about the rest.  :)
>
>




Design by contract is complementary to unit testing (I notice that the  
author of PEP 316 appears confused about this).  DbC is, roughly  
speaking, about explicit allocation of responsibility.  Consider this  
contrived example.

def foo(s):
     require(s is not None)
     //code
     ensure(hasattr(returnValue, '__iter__'))


The require condition tells you that it's the caller's responsibility  
to pass a non-nil argument to foo.  The ensure condition is a  
guarantee that foo will return something suitable for iteration, if  
the precondition in the require condition is satisfied.  These  
conditions can be enforced at runtime, but may not be, for reasons of  
performance.

DbC is in fact about not *always* checking the input/output of  
functions; on the contrary, Bertrand Meyer, the inventor of DbC,  
claims that DbC allows one to eliminate such redundancy, and the  
resulting overhead.

Charles Yeomans