<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 14, 2009, at 12:09 AM, Scott David Daniels wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Charles Yeomans wrote:<br><blockquote type="cite">On Aug 11, 2009, at 3:30 PM, Ethan Furman wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Ethan Furman wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Greetings!<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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 (<a href="http://www.wayforward.net/pycontract/">http://www.wayforward.net/pycontract/</a>) 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 ;)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">~Ethan~<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hmmm...<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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. :)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite">def foo(s):<br></blockquote><blockquote type="cite"> require(s is not None)<br></blockquote><blockquote type="cite"> //code<br></blockquote><blockquote type="cite"> ensure(hasattr(returnValue, '__iter__'))<br></blockquote><br>yo might want two flags, REQUIRE_OFF, and ENSURE_ON that control<br>testing, and change the code above to:<br> require(REQUIRE_OFF or s is not None)<br> //code<br> ensure(ENSURE_OFF or hasattr(returnValue, '__iter__'))<br><br>Python has no good way to turn off argument calculation by<br>manipulating function definition (at least that I know of).<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>For this purpose, it had occurred to me to do something like the following.</div><div><br></div><div>def require(condition):</div><div> if condition:</div><div> return True</div><div> else:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>raise PreconditionFailure</div><div><br></div><div><br></div><div><div>def foo(s):<br> assert require(s is not None)</div><div><br></div><div><br></div><div>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</div><div><br></div><div>assert precondition, "PreconditionFailure"</div><div><br></div><div>though I think I prefer the former.</div><div><br></div><div><br></div><div>Charles Yeomans </div></div></body></html>