Programming by Contract

Ethan Furman ethan at
Tue Aug 11 23:20:18 CEST 2009

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 
>>> ( ) 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.


More information about the Python-list mailing list