status of Programming by Contract (PEP 316)?

Steve Holden steve at
Sat Sep 1 14:38:12 CEST 2007

Bryan Olson wrote:
> 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 agree that programming-in-the-large brings with it problems that 
aren't experienced in smaller scale projects such as the ones I mentioned.

> 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.
This is the kind of realism I like to see in engineering. I am always 
suspicious when any method is promoted as capable of reducing the error 
rate to zero.
> 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.
Python's dynamic nature certainly makes it more difficult to reason 
about programs in any formal sense. I've always thought of it as a 
pragmatist's language, and we need to be pragmatic about the downside as 
well as the upside.

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd 
Skype: holdenweb
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

More information about the Python-list mailing list