status of Programming by Contract (PEP 316)?

[Chris Mellon]

On 8/29/07, Russ <uymqlp502 at sneakemail.com> wrote:
> On Aug 28, 10:58 pm, Michele Simionato <michele.simion... at gmail.com>
> wrote:
>
> > Why do you think that would ad a strong positive capability?
> > To me at least it seems a big fat lot of over-engineering, not
> > needed in 99% of programs. In the remaining 1%, it would still not
> > be needed since Python provides out of the box very powerful
> > metaprogramming capabilities so that you can implement
> > yourself the checks you need, if you really need them.
>
> I get the strong impression you don't really understand what
> programming by contract is.
>

Don't be condescending.

> I have not yet personally used it, but I am interested in anything
> that can help to make my programs more reliable.

The entire issue of software reliability, exactly what metrics you
should use to measure it, and whether any specific technique results
in more of it are very much in debate. If you want to experiment with
these techniques, you can do so without them being in the Python core.
Python has all the support you need to play with them right now.

>If you are
> programming something that doesn't really need to be correct, than you
> probably don't need it. But if you really need (or want) your software
> to be correct and reliable as possible, I think you you should be
> interested in it. You might want to read this:
>

You don't want your software to KILL BABIES, do you? If you don't want
your programs to KILL BABIES then you should use our technique, so you
don't KILL BABIES.

There are ways to make correct programs besides DBC. It may not even
help in the general case - just as with unit testing and type proving,
you're going to be limited by what you don't think to assert or
document or test, and I've seen no evidence that DBC is any better
than anything else at preventing unwritten assumptions.