Programming by Contract

[Ethan Furman]

Charles Yeomans wrote:
> 
> 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

Many thanks!

So if I understand -- Python's EAFP fits well with DbC, as DbC seems 
well suited to say, "This is your responsibility, and this is mine," 
stated in programming terms (who needs comments? ;)  Combined with unit 
testing (which should be easier to design correctly given the DbC code), 
healthy code seems more attainable.

Interesting.  Thank you for the information.

~Ethan~