status of Programming by Contract (PEP 316)?

[Paul Rubin]

Russ <uymqlp502 at sneakemail.com> writes:
> > try:
> >   blah blah with as many return statements as you want
> > finally:
> >   something that gets executed unconditionally at the end
> Thanks. I didn't think of that.
> So design by contract *is* relatively easy to use in Python already.
> The main issue, I suppose, is one of aesthetics. Do I want to use a
> lot of explicit function calls for pre and post-conditions and "try/
> finally" blocks in my code to get DbC (not to mention a global
> variable to enable or disable it)?

I still don't understand why you don't like the decorator approach,
which can easily implement the above.

> I personally use Python for its clean syntax and its productivity with
> my time, so I am certainly not denigrating it. For the R&D work I do,
> I think it is very appropriate. But I did raise a few eyebrows when I
> first started using it. I used C++ several years ago, and I thought
> about switching to Ada a few years ago, but Ada just seems to be
> fading away (which I think is very unfortunate, but that's another
> story altogether).

It seems to be getting displaced by Java, which has some of the same
benefits and costs as Ada does.  

I've gotten interested in static functional languages (including proof
assistants like Coq, that can generate certified code from your
mechanically checked theorems).  But I haven't done anything serious
with any of them yet.  I think we're in a temporary situation where
all existing languages suck (some more badly than others) but the
functional languages seem like a more promising direction to get out
of this hole.