status of Programming by Contract (PEP 316)?

[Bryan Olson]

Steve Holden wrote:
[...]
> If I can blow my own trumpet briefly, two customers (each using over 25 
> kLOC I have delivered over the years) ran for two years while I was away 
> in the UK without having to make a single support call. One of the 
> systems was actually locked in a cupboard all that time (though I have 
> since advised that client to at least apply OS patches to bring it up to 
> date).

> This was achieved by defensive programming, understanding the user 
> requirements and just generally knowing what I was doing.

On the one hand, nice work. Made your customers happy and kept
them happy. Can't argue with success. On the other hand, 25K lines
is tiny by software engineering standards. If a support call would
have to go to you, then the project must be small. Software
engineering is only a little about an engineer knowing or not
knowing what he or she is doing; the bigger problem is that
hundreds or thousand of engineers cannot possibly all know what
all the others are doing.

I work on large and complex systems. If I screw up -- O.K., face
facts: *when* I screw up -- the chance of the issue being assigned
to me is small. Other engineers will own the problems I cause,
while I work on defects in code I've never touched. I wish I could
own all my own bugs, but that's not how large and complex systems
work. Root-cause analysis is the hard part. By the time we know
what went wrong, 99.99% of the work is done.


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.


-- 
--Bryan