status of Programming by Contract (PEP 316)?

[Russ]

> I disagree. IMO automatic testing is thousands of times better than
> design by contract and Python has already all the support you need
> (unittest, doctest, py.test, nose, ...)

In theory, anything you can verify with "design by contract" you can
also verify with unittest and the rest. However, "design by contract"
has a major practical advantage: if you have real (or simulated)
inputs available, you don't need to write a test driver or generate
test inputs for each class or function.

All you need to do is to run your program with the real (or simulated)
inputs, all the internal data that gets passed around between classes
and functions gets generated as usual, and everything gets tested
automatically. In other words, you are spared the potentially
considerable effort of generating and storing samples of all the
internal data that gets passed around internally.

You may want to do unit tests also, of course. Separate unit tests
will give you more control and allow you to test individual classes
and functions using a wider variety of inputs. But if your design by
contract is comprehensive (i.e., passing it guarantees correct
functioning of your code), then your unit tests can simply make use of
the tests already available in the design by contract. So you've done
no extra work in setting up the design by contract anyway.

Another significant advantage of "design by contract" is that the
tests are all right there in your source code, where they are much
less likely to get lost or ignored by subsequent programmers who need
to maintain the code.  Relying on separate units tests is a bit like
relying on extended "comments" or design documents that are separate
from the code. Yes, those are certainly useful, but they do not
eliminate the need for comments in the code.