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