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 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~
--
http://mail.python.org/mailman/listinfo/python-list
