[EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
