On Sep 1, 4:25 am, Bryan Olson > Design-by-contract (or programming-by-contract) shines in large > and complex projects, though it is not a radical new idea in > software engineering. We pretty much generally agree that we want > strong interfaces to encapsulate implementation complexity. > That's what design-by-contract is really about. > > There is no strong case for adding new features to Python > specifically for design-by-contract. The language is flexible > enough to support optionally-executed pre-condition and > post-condition checks, without any extension. The good and bad > features of Python for realizing reliable abstraction are set > and unlikely to change. Python's consistency and flexibility > are laudable, while duck-typing is a convenience that will > always make it less reliable than more type-strict languages.
Excellent points. As for "no strong case for adding new features to Python specifically for design-by-contract," if you mean adding something to language itself, I agree, but I see nothing wrong with adding it to the standard libraries, if that is possible without changing the language itself. Someone please correct me if I am wrong, but I think PEP adds only to the libraries. -- http://mail.python.org/mailman/listinfo/python-list
