473,883 Members | 1,527 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 2859
Russ a ťcrit :
>FWIW, the "Eiffel and SPARK Ada folks" also "brilliantl y explained" why
one can not hope to "write reliable programs" without strict static
declarative type-checking.

And they are probably right.
And they are obviously wrong, by empiric experience.
I don't think you understand what they mean by "reliable
programs."
I think you should stop over-estimating yourself, and start realizing
that there are quite a lot of experimented programmers here.
The important question is this: why do I waste my time with bozos like
you?
The same question is probably crossing the mind of quite a lot of people
here - but the 'bozo' might not be who you think.

Aug 31 '07 #41
On Aug 31, 10:02 am, Russ <uymqlp...@snea kemail.comwrote :
>
Hi Alex. I've always enjoyed your Piggies talks at
Google (although I missed he last one because I was out
of town). I'm disappointed to see that you seem to have
taken personal offense from remarks I made to someone else who
attacked me first.
I am curious. Why do you think I attacked you? The conversion went as
follows:
On Aug 29, 7:21 am, Russ <uymqlp...@snea kemail.comwrote :
>Thanks for that information. That's too bad, because it seems like a
strong positive capability to add to Python. I wonder why the cold
reception. Were there problems with the idea itself or just the
implementation ? Or is it just a low priority?
me:
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.
Basically you said "I think DbC is good" and I said "I don't think
so".
I would not call that an attack. If you want to see an attack, wait
for
Alex replying to you observations about the low quality of code at
Google! ;)

Michele Simionato

Aug 31 '07 #42
Michele Simionato <mi************ ***@gmail.comwr ites:
http://archive.eiffel.com/doc/manual...ct/ariane/page...

That paper contains only a good think: a link to the contrarian view
http://home.flash.net/~kennieg/ariane.html#s3.1.5
I like the contrarian article much better than the Eiffel sales pitch.
Aug 31 '07 #43
Russ wrote:
>I've always wondered... Are the compilers (or interpreters), which take
these programs to machine code, also formally proven correct?

No, they are not formally proven correct (too complicated for that),
but I believe they are certified to a higher level than your "typical"
compiler. I think that Ada compilers used for certain safety-critical
applications must meet higher standards than, say, GNU Ada, for
example.

And the OS
>in which those programs operate, are they also formally proven correct?

Same as above, if I am not mistaken.
>And the hardware, microprocessor, electric supply, etc. are they also
'proven correct'?

I think the microprocessors used for flight control, for example, are
certified to a higher level than standard microprocessors .

How would you prove a power supply to be "correct"? I'm sure they meet
higher reliability standards too.

In that case why don't we just 'certify to a higher level' the programs
and get done with this formal proofs? We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component, so either we formally prove all those other very
important components (OS gets MUCH more use than the program (the
program uses it for almost every other action)) or get done with the
whole fuss.
Aug 31 '07 #44
Ricardo ArŠoz <ri******@gmail .comwrites:
In that case why don't we just 'certify to a higher level' the programs
and get done with this formal proofs? We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component, so either we formally prove all those other very
important components (OS gets MUCH more use than the program (the
program uses it for almost every other action)) or get done with the
whole fuss.
This url has some info on the topic of certification etc.:

http://www.dwheeler.com/essays/high-...nce-floss.html

Aug 31 '07 #45
On 2007-08-31, Ricardo ArŠoz <ri******@gmail .comwrote:
Russ wrote:
>Yes, thanks for reminding me about that. With SPARK Ada, it is
possible for some real (non-trivial) applications to formally
(i.e., mathematically) *prove* correctness by static analysis.
I doubt that is possible without "static declarative type-
checking."

SPARK Ada is for applications that really *must* be correct or
people could die.

I've always wondered... Are the compilers (or interpreters),
which take these programs to machine code, also formally proven
correct? And the OS in which those programs operate, are they
also formally proven correct? And the hardware, microprocessor,
electric supply, etc. are they also 'proven correct'?
Who watches the watchmen? The contracts are composed by the
programmers writing the code. Is it likely that the same person
who wrote a buggy function will know the right contract?

--
Neil Cerutti
The third verse of Blessed Assurance will be sung without musical
accomplishment. --Church Bulletin Blooper
Aug 31 '07 #46
Michele Simionato <mi************ ***@gmail.comwr ote:
...
I would not call that an attack. If you want to see an attack, wait
for
Alex replying to you observations about the low quality of code at
Google! ;)
I'm not going to deny that Google Groups has glitches, particularly in
its user interface (that's why I'm using MacSOUP instead, even though
Groups, were it perfect, would offer me a lot of convenience).

We have a LOT of products (see
<http://www.google.com/intl/en/options/index.html>, plus a few more at
<http://labs.google.com/>;
<http://en.wikipedia.or g/wiki/List_of_Google_ productsfor an overview,
<http://searchenginelan d.com/070220-091136.phpfor a list of more
lists...), arguably too many in the light of the "It's best to do one
thing really, really well" ``thing we've found to be true''; given the
70-20-10 rule we use (we spend 70% of our resources on search and ads
[and of course infrastructure supporting those;-)], 20% on "adjacent
businesses" such as News, Desktop and Maps, 10% on all the rest
combined), products in the "other" (10%) category may simply not receive
sufficient time, resources and attention.

We've recently officially raised "Apps" to the status of a third pillar
for Google (after Search and Ads), but I don't know which of our many
products are officially within these pillar-level "Apps" -- maybe a good
starting hint is what's currently included in the Premier Edition of
Google Apps, i.e.: Gmail (with 99.9% uptime guarantee), Google Talk,
Google Calendar, Docs & Spreadsheets, Page Creator and Start Page.

I do notice that Google Groups is currently not in that "elite" (but
then, neither are other products we also offer in for-pay editions, such
as Google Earth and Sketchup) but I have no "insider information" as to
what this means or portends for the future (of course not: if I _did_
have insider information, I could not talk about the subject!-).

Notice, however, that none of these points depend on use of Python vs
(or side by side with) other programming languages, DbC vs (or side by
side with) other methodologies, and other such technical and
technological issues: rather, these are strategical problems in the
optimal allocation of resources that (no matter how abundant they may
look on the outside) are always "scarce" compared to the bazillion ways
in which they _could_ be employed -- engineers' time and attention,
machines and networking infrastructure, and so forth.
Alex
Aug 31 '07 #47
Russ wrote:
>I've always wondered... Are the compilers (or interpreters), which take
these programs to machine code, also formally proven correct?

No, they are not formally proven correct (too complicated for that),
but I believe they are certified to a higher level than your "typical"
compiler. I think that Ada compilers used for certain safety-critical
applications must meet higher standards than, say, GNU Ada, for
example.

And the OS
>in which those programs operate, are they also formally proven correct?

Same as above, if I am not mistaken.
>And the hardware, microprocessor, electric supply, etc. are they also
'proven correct'?

I think the microprocessors used for flight control, for example, are
certified to a higher level than standard microprocessors .

How would you prove a power supply to be "correct"? I'm sure they meet
higher reliability standards too.

"... I believe ...", "... if I am not mistaken", "I think ...".

Well, all this certainty you are expressing will surely allow this bozo
to sleep more soundly in his bed.

Frankly I am getting a little tired of they way you are unable to even
recognize that your readers may well have a sensible appreciation of the
difficulties about which you write. As has been pointed out already,
many readers here are extremely experienced programmers.

You said in an earlier post "that's not an insult", but that isn't
really up to you to decide. If it gives offense then it probably is,
whether it was intended to do so or not. You don't seem to appreciate
the insulting nature of your tone, and calling people bozos is not
likely to endear you to most c.l.py readers since it comes off as arrogant.

Given that you now profess no absolute certainty on fairly simple
matters connected to safety-critical systems I wish you'd step down off
your platform and join the rest of us.

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 -------------

Aug 31 '07 #48

Michele Simionato wrote:
I am curious. Why do you think I attacked you? The conversion went as
follows:
I don't think you attacked me. I was referring to another person, who
apparently came to your
defense and *did* attack me.

For the record, I apologize for saying that you don't seem to know
what DbC is. I shouldn't
have made it personal. I should have just made the points I made and
let them stand on their
own.

Having said that, I think that some of the statements you made were
clearly excessive.
Unit testing is a thousand times better than DbC? How could that
possibly be? As I
tried to explain, DbC can be *used* for unit testing and *also* for
integrated system testing.
I would not call that an attack. If you want to see an attack, wait
for
Alex replying to you observations about the low quality of code at
Google! ;)
I don't know much about Google code, but I know that the line breaking
logic (or lack
thereof) on Google Groups is a constant annoyance to me. But maybe I
just haven't
figured out how to use it yet.

Aug 31 '07 #49

Steve Holden wrote:
Frankly I am getting a little tired of they way you are unable to even
recognize that your readers may well have a sensible appreciation of the
difficulties about which you write. As has been pointed out already,
many readers here are extremely experienced programmers.
You said in an earlier post "that's not an insult", but that isn't
really up to you to decide. If it gives offense then it probably is,
whether it was intended to do so or not. You don't seem to appreciate
the insulting nature of your tone, and calling people bozos is not
likely to endear you to most c.l.py readers since it comes off as arrogant.
You quoted what I wrote in reply to a personal attack against me, but
you conveniently
neglected to quote the original insult that I was replying to. OK,
I'll concede that I shouldn't
have replied to a personal insult with another insult, but why am I
the only one at fault here
rather than the guy who started it?

Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior
here, where
"outsiders" like me are held to a higher standard than your "insider"
friends. I don't know
who you are, nor do I care what you and your little group think about
me.

As for DbC or what I call "self-testing code," I have come to the
(tentative) realization that
it is easy to implement in current Python -- without resorting to the
"decorators " hack.
OK, maybe this should have been obvious to me from the
start, but here goes:

All you really need to test the pre-conditions of a function
is a call at the top of the function to another function that checks
the inputs. To test the
post-conditions, you just need a call at the bottom of the function,
just before the return,
that checks the return values. Those functions can also check the
invariants. Then you
define a global variable to switch all the self-test functions on or
off at once.

An advantage of this approach is that all the self tests can be put at
the bottom of the file
(or perhaps in another file) to reduce "clutter" in the primary code.

I'd still prefer PEP 316, but this seems like a reasonable
alternative.

One suggestion I have for PEP 316 is to provide a way to place the
self-test
checks in a separate file to reduce clutter.

Aug 31 '07 #50

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.