> 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. -- http://mail.python.org/mailman/listinfo/python-list
