Charles Yeomans wrote:
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
And in either case, since such checks can have a *huge* impact on
performance, it is good that asserts can be disabled with the -O
optimize switch. So it's also good that the original design for DbC was
an _understanding_ of who is responsible for what, as opposed to _code_
to actually enforce it.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
