Programming by Contract

[Charles Yeomans]

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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090814/81eea872/attachment.html>