473,836 Members | 1,586 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

status of Programming by Contract (PEP 316)?

I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on
comp.lang.pytho n,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.

Aug 29 '07
81 2828
"Carl Banks" <pavl....mail.c omwrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad web search is even
comparable to the most important systems on airplanes, nuclear reactors,
dams, and so on? Come on.
This really intrigues me - how do you program a dam? - and why is it
critical?

Most dams just hold water back.

Dam design software - well yes that I would agree is critical.
Is that what you mean?

- Hendrik
Sep 1 '07 #61
On Sat, 01 Sep 2007 10:34:08 +0200, Hendrik van Rooyen wrote:
"Carl Banks" <pavl....mail.c omwrote:
>This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad web search is even
comparable to the most important systems on airplanes, nuclear reactors,
dams, and so on? Come on.

This really intrigues me - how do you program a dam? - and why is it
critical?

Most dams just hold water back.
And some produce electricity. And most if not all can regulate how many
water is let through. If something goes wrong the valley behind the dam
gets flooded. If this is controlled by a computer you have the need for
reliable software.

Ciao,
Marc 'BlackJack' Rintsch
Sep 1 '07 #62
On 29 Aug., 13:45, Russ <uymqlp...@snea kemail.comwrote :
I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. 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
I'm one of the few (thousand) hard core Eiffel programmers on this
world
and i can tell you that this would not add to much to python. To get
the
benefits of it you need to use it together with a runtime that is
designed
from ground with DBC and a language that is fast enough to be able to
check the contracts, if you don't have the latter all you get is a
better
specification language (which you can write as comments in python).

Learn the Eiffel design way and then add assert statements whereever
you
need them. Works well when i do C/C++ programming and maybe even for
script languages - but i never used it for scripts as i don't see a
real
value here.

Sep 1 '07 #63
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

Sep 1 '07 #64
Carl Banks wrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad web search is even
comparable to the most important systems on airplanes, nuclear reactors,
dams, and so on? Come on.
Who said they were the same? I said that just because it doesn't take lives
it doesn't mean it isn't important. I wasn't going to reply to not extend
this, but this misunderstandin g of your was bugging me.

I use Python on systems that deal with human health and wrong calculations
may have severe impact on a good sized population. Using Python.

As with nuclear reactors, dams, airplanes and so on we have a lot of
redundancy and a lot of checkpoints. No one is crazy to take them out or
even to remove some kind of dispositive to allow manual intervention at
critical points.
Sep 1 '07 #65
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.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
Sep 1 '07 #66
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.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

Sep 1 '07 #67
Hendrik van Rooyen wrote:
"Carl Banks" <pavl....mail.c omwrote:
>This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad web search is even
comparable to the most important systems on airplanes, nuclear reactors,
dams, and so on? Come on.

This really intrigues me - how do you program a dam? - and why is it
critical?

Most dams just hold water back.

Dam design software - well yes that I would agree is critical.
Is that what you mean?

- Hendrik
Yup! He was referring to that Damn design software. Just as almost
everyone has at one time or another. ;c)
Sep 1 '07 #68
Carl Banks a écrit :
>
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad web search is even
comparable to the most important systems on airplanes, nuclear reactors,
dams, and so on? Come on.
20 years ago, there was *no* computer at all in nuclear reactors.
Sep 1 '07 #69

"Hendrik van Rooyen" <ma**@microcorp .co.zawrote in message
news:026201c7ec 75$07d6e0c0$030 00080@hendrik.. .
| This really intrigues me - how do you program a dam? - and why is it
| critical?
|
| Most dams just hold water back.

Most big dams also generate electricity. Even without that, dams do not
just hold water back, they regulate the flow over a year or longer cycle.
A full dam is great for power generation and useless for flood control. An
empty dam is great for flood control and useless for power generation. So
both power generation and bypass release must be regulated in light of
current level, anticipated upstream precipitation, and downstream
obligations. Downstream obligations can include both a minimum flow rate
for downstream users and a maximum rate so as to not flood downstream
areas.

tjr

Sep 1 '07 #70

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.