status of Programming by Contract (PEP 316)?

[Chris Mellon]

On 8/29/07, Russ <uymqlp502 at sneakemail.com> wrote:
>
> > 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.
>

PEP 316 introduces new syntax for a limited use feature. That's pretty
much a no-starter, in my opinion, and past experience tends to bear
that out. Furthermore, it predates decorators  and context managers,
which give all the syntax support you need and let you move the actual
DBC features into a library. I can't remember if I mentioned this
before but I believe that Philip Ebys PEAK toolkit has some stuff you
could use for DBC.

> 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.
>

If a well written contract library were to exist, and people were to
use it, and the author were interested, it would make a decent
candidate for inclusion in the standard library, and I wouldn't oppose
such a thing (for all my opinion is worth, ie essentially nothing).
The PEP 316 special syntax is another matter entirely.

The best way for this to happen is for you to find or write such a
library, and use it to write good code.