Programming by Contract

[Scott David Daniels]

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__'))

yo might want two flags, REQUIRE_OFF, and ENSURE_ON that control
testing, and change the code above to:
       require(REQUIRE_OFF or s is not None)
       //code
       ensure(ENSURE_OFF or hasattr(returnValue, '__iter__'))

Python has no good way to turn off argument calculation by
manipulating function definition (at least that I know of).

--Scott David Daniels
Scott.Daniels at Acm.Org