Programming by Contract

[Ethan Furman]

Charles Yeomans wrote:
> 
> On Aug 14, 2009, at 12:09 AM, Scott David Daniels wrote:
> 
>> 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).
>>
> 
> For this purpose, it had occurred to me to do something like the following.
> 
> def require(condition):
>     if condition:
>         return True
>     else:
> raise PreconditionFailure
> 
> 
> def foo(s):
>    assert require(s is not None)
> 
> 
> Then it occurred to me to actually read the assert documentation, where 
> I learned that one can pass a second expression to assert. So instead 
> one might write
> 
> assert precondition, "PreconditionFailure"
> 
> though I think I prefer the former.
> 
> 
> Charles Yeomans 
> 

And in either case, since such checks can have a *huge* impact on 
performance, it is good that asserts can be disabled with the -O 
optimize switch.  So it's also good that the original design for DbC was 
an _understanding_ of who is responsible for what, as opposed to _code_ 
to actually enforce it.

~Ethan~