Programming by Contract

[shaileshkumar]

zope.interface provides extensive support for design by contract.
http://pypi.python.org/pypi/zope.interface.
This package can be used independently of zope in other projects.
- Shailesh

On Aug 12, 2:20 am, Ethan Furman <et... at stoneleaf.us> 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__'))
>
> > 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~