status of Programming by Contract (PEP 316)?

[Robert Brown]

aleax at mac.com (Alex Martelli) writes:
> DbC and allegedly rigorous compile-time typechecking (regularly too weak
> due to Eiffel's covariant vs countervariant approach, btw...), based on
> those empirical results, appear to be way overhyped.

My experience with writing Eiffel code was a bit different.  Integrating
code from multiple sources happened much faster than I expected, and the
code ran reliably.  There were a couple of instances where previously
uncombined code was linked together and worked on the first run.

Perhaps more important, however, is that method contracts provide important
documentation about how each method is supposed to work -- what it assumes
and what must be true when it returns.  Using Eiffel changed my coding
process.  Often I'd write the pre- and postconditions first, then write the
method body, just as programmers today often write unit tests first.
Thinking carefully about the contracts and writing them down, so they could
be verified, makes the code more reliable and maintainable.  The contracts
are part of the source code, not a fuzzy concept in each programmer's head.

The contracts are also useful when discussing the code with domain experts
who are not programmers.  They can read and understand the "flat short" view
of a class, which includes all the method names, method comments, and
contracts, but leaves out the method implementations.  Here's an example,
Eiffel's String class: http://www.nenie.org/eiffel/flatshort/string.html

In any case, I'm still not sure whether it would be useful to integrate DbC
into Python.  A library that implements DbC for Common Lisp has not gotten
much traction in that community, which has a similar style of software
development.  Perhaps it's just too much to ask that programmers write both
unit tests and method contracts.

bob