status of Programming by Contract (PEP 316)?

[Russ]

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.