status of Programming by Contract (PEP 316)?

[Russ]

> But it's always a good idea to make your software "correct and as
> reliable as possible", isn't it? The problem is the external constraints
> on the project. As the old saying goes: "Cheap, fast, reliable: choose
> any two".

If you are suggesting that "programming by contract" is not
appropriate for every application, you will get no argument from me.
All I am suggesting is that having the option to use it when you need
it is very desirable, and it can possibly enhance the versatility of
Python by making Python more suitable for *some* mission-critical
applications.

I once read a book on something called SPARK Ada, which also supports
programming by contract. I was pleasantly surprised to discover
yesterday that support for the such methods is also available for
Python. However, the support would obviously be a bit stronger if it
were in the core Python distribution.

What I really like about the implementation I cited above is that the
invariants and the pre and post-conditions can all be put right in the
doc string at the beginning of each class or function. You can think
of it as a detailed specification of the intent (or of some of the
requirements or constraints) of the class or function -- which can be
*automatically* checked during testing. It can also be used for
explicit type checking.

It's like having some of your most critical unit tests built right
into your code. It may make your code very verbose, but it will also
be very complete.