Re: status of Programming by Contract (PEP 316)?

2007-09-03 Thread Bruno Desthuilliers
Russ a écrit :
(snip)

 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.

If you took time to follow discussions on this group, you'd notice that 
newcomers are usually welcome. It's not a problem of being an outsider 
of an insider, and there's nothing clannish (or very few, specially 
when compared to some other places on usenet), it's mostly a problem 
with your attitude. And please notice, once again, that I'm not talking 
about *you* - as a person - but about how you behave(d).

(snip)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-02 Thread Paul Rubin
Russ [EMAIL PROTECTED] 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 RD 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-02 Thread Russ
On Sep 1, 10:05 pm, Russ [EMAIL PROTECTED] wrote:

 changing the language itself. Someone please correct me if I am wrong,
 but I think PEP adds only to the libraries.

I meant to write PEP 316, of course.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-02 Thread Russ
On Sep 1, 11:04 pm, Paul Rubin wrote:

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

Well, maybe decorators are the answer. If a function needs only one
decorator for all the conditions and invariants (pre and post-
conditions), and if it can just point to functions defined elsewhere
(rather than defining everything inline), then perhaps they make
sense. I guess I need to read up more on decorators to see if this is
possible.

In fact, the ideal would be to have just a single decorator type, say
contract or self_test, that takes an argument that points to the
relevant functions to use for the function that the decorator applies
to. Then the actual self-test functions could be pushed off somewhere
else, and the footprint on the primary code would be minimal

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-02 Thread Ricardo Aráoz
Alex Martelli wrote:
 Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
 We should remember that the level
 of security of a 'System' is the same as the level of security of it's
 weakest component,
...
 You win the argument, and thanks you prove my point. You typically
 concerned yourself with the technical part of the matter, yet you
 completely ignored the point I was trying to make.
 
 That's because I don't particularly care about the point you were
 trying to make (either for or against -- as I said, it's a case of ROI
 for different investments [in either security, or, more germanely to
 this thread, reliability] rather than of useful/useless classification
 of the investments), while I care deeply about proper system thinking
 (which you keep failing badly on, even in this post).

And here you start, followed by 'F- at system thinking', 'glib and false
assertions', 'falsities', etc.
I don't think you meant anything personal, how could you, we don't know
each other. But the outcome feels like a personal attack instead of an
attack on the ideas exposed.
If that's not what you intended, you should check your communication
abilities and see what is wrong. If that is what you meant well...

So I will not answer your post. I'll let it rest for a while till I
don't feel the sting, then I'll re-read it and try to learn as much as I
can from your thoughts (thank you for them). And even though some of
your thinking process I find objectionable I will not comment on it as
I'm sure it will start some new flame exchange which will have a lot to
do with ego and nothing to do with python.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-02 Thread Aahz
In article [EMAIL PROTECTED],
Russ  [EMAIL PROTECTED] wrote:

Excellent points. As for no strong case for adding new features to
Python specifically for design-by-contract, if you mean adding
something to language itself, I agree, but I see nothing wrong with
adding it to the standard libraries, if that is possible without
changing the language itself. Someone please correct me if I am wrong,
but I think PEP adds only to the libraries.

You're wrong, but even aside from that, libraries need to prove
themselves useful before they get added.
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important. --Henry Spencer
http://www.lysator.liu.se/c/ten-commandments.html
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Carl Banks
On Fri, 31 Aug 2007 22:18:09 -0300, Jorge Godoy wrote:

 Russ wrote:
 
 Alex, I think you are missing the point. Yes, I'm sure that web
 searches are critical to
 Google's mission and commercial success. But the point is that a few
 subtle bugs cannot
 destroy Google. If your search engines and associated systems have
 bugs, you fix them
 (or simply tolerate them) and continue on. And if a user does not get
 the results he wants,
 he isn't likely to die over it -- or even care much.
 
 But if this pattern of not getting wanted results is common, then the
 user will migrate to alternative search engines and this will *kill* the
 business.  Wrong results won't impact ONE search, but many will impact
 the company business and will be part of the recipe to take it out of
 business.
 
 Online financial transactions are another matter altogether, of course.
 User won't die, but
 they will get very irate if they lose money. But I don't think that's
 what you are talking about
 here.
 
 Lets make someone loose his job and have all his money commitments
 compromised because of this money lost and we might be talking about
 people taking their lives.
 
 Again, this isn't 100% sure to happen, but it *can* happen.
 
 As it happens with a peacemaker: the user won't die if his heart skips
 one beat, but start skipping a series of them and you're incurring in
 serious problems.
 
 Just because the result isn't immediate it doesn't mean it isn't
 critical.

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.

BTW, I'm not really agreeing with Russ here.  His suggestion (that 
because Python is not used in highly critical systems, it is not suitable 
for them) is logically flawed.  And Alex's point, that Python has a good 
track record of reliabilty (look at Google's 99.9% uptime) is valid 
whether Google is a critical system or not.

So please leave the laughable comparisons between flight systems and web 
searches out of it.  It's unnecessary and makes Pythoners look bad.


Carl Banks

(P.S. 99.9% uptime would be a critical flaw in the systems I work on.)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Paul Rubin
Russ [EMAIL PROTECTED] writes:
 The idea here is that errors in the self-testing code are unlikely
 to be correlated with errors in the primary code. Hence, you get a
 sort of multiplying effect on reliability. For example, if the
 chance of error in the primary code and the self-test code are each
 0.01, the chance of an undetected error is approximately 0.01^2 or
 0.0001.

But I think you give a lot of that back when you turn the checks off.
The errors you detect when the checks are enabled are only the ones
that result from your test data.  Turn off the checks and expose the
application to data from a potentially different distribution, and
you're back where you started.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Hendrik van Rooyen
 Carl Banks pavlmail.com 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.

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


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Marc 'BlackJack' Rintsch
On Sat, 01 Sep 2007 10:34:08 +0200, Hendrik van Rooyen wrote:

 Carl Banks pavlmail.com 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.
 
 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread llothar
On 29 Aug., 13:45, Russ [EMAIL PROTECTED] wrote:

 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Jorge Godoy
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 misunderstanding 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.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Steve Holden
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 -
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Ricardo Aráoz
Hendrik van Rooyen wrote:
  Carl Banks pavlmail.com 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.
 
 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)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Pierre Hanser
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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Terry Reedy

Hendrik van Rooyen [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
| 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



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Alex Martelli
Ricardo Aráoz [EMAIL PROTECTED] wrote:
   ...
 We should remember that the level
 of security of a 'System' is the same as the level of security of it's
 weakest component,

Not true (not even for security, much less for reliability which is
what's being discussed here).

It's easy to see how this assertion of yours is totally wrong in many
ways...

Example 1: a toy system made up of subsystem A (which has a probability
of 90% of working right) whose output feeds into subsystem B (which has
a probability of 80% of working right).  A's failures and B's faliures
are statistically independent (no common-mode failures, c).

The ``level of goodness'' (probability of working right) of the weakest
component, B, is 80%; but the whole system has a ``level of goodness''
(probability of working right) of just 72%, since BOTH subsystems must
work right for the whole system to do so.  72 != 80 and thus your
assertion is false.

More generally: subsystems in series with independent failures can
produce a system that's weaker than its weakest component.


Example 2: another toy system made up of subsystems A1, A2 and A3, each
trying to transform the same input supplied to all of them into a 1 bit
result; each of these systems works right 80% of the time, statistically
independently (no common-mode failures, c).  The three subsystems'
results are reconciled by a simple majority-voting component M which
emits as the system's result the bit value that's given by two out of
three of the Ai subsystems (or, of course, the value given unanimously
by all) and has extremely high reliability thanks to its utter
simplicity (say 99.9%, high enough that we can ignore M's contribution
to system failures in a first-order analysis).

The whole system will fail when all Ai fail together (probability
0.2**3) or when 2 out of them fail while the hird one is working
(probability 3*0.8*0.2**2):

 0.2**3+3*0.2**2*0.8
0.10404

So, the system as a whole has a level of goodness (probability of
working right) of almost 90% -- again different from the weakest
component (each of the three Ai's), in this case higher.

More generally: subsystems in parallel (arranged so as to be able to
survive the failure of some subset) with indipendent failures can
produce a system that's stronger than its weakest component.


Even in the field of security, which (changing the subject...) you
specifically refer to, similar considerations apply.  If your assertion
was correct, then removing one component would never WEAKEN a system's
security -- it might increase it if it was the weakest, otherwise it
would leave it intact.  And yet, a strong and sound tradition in
security is to require MULTIPLE components to be all satisfied e.g. for
access to secret information: e.g. the one wanting access must prove
their identity (say by retinal scan), possess a physical token (say a
key) AND know a certain secret (say a password).  Do you really think
that, e.g., removing the need for the retinal scan would make the
system's security *STRONGER*...?  It would clearly weaken it, as a
would-be breaker would now need only to purloin the key and trick the
secret password out of the individual knowing it, without the further
problem of falsifying a retinal scan successfully.  Again, such security
systems exist and are traditional exactly because they're STRONGER than
their weakest component!


So, the implication accompanying your assertion, that strenghtening a
component that's not the weakest one is useless, is also false.  It may
indeed have extremely low returns on investment, depending on system's
structure and exact circumstances, but then again, it may not; nothing
can be inferred about this ROI issue from the consideration in question.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Alex Martelli
Russ [EMAIL PROTECTED] wrote:
   ...
   the inputs. To test the
   post-conditions, you just need a call at the bottom of the function,
   just before the return,
   ...
  there's nothing to stop you putting the calls before every return.
 
 Oops! I didn't think of that. The idea of putting one before every
 return certainly doesn't appeal to me. So much for that idea.

try:
  blah blah with as many return statements as you want
finally:
  something that gets executed unconditionally at the end

You'll need some convention such as all the return statements are of
the same form ``return result'' (where the result may be computed
differently each time), but that's no different from the conventions you
need anyway to express such things as ``the value that foobar had at the
time the function was called''.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Ricardo Aráoz
Alex Martelli wrote:
 Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
 We should remember that the level
 of security of a 'System' is the same as the level of security of it's
 weakest component,
 
 Not true (not even for security, much less for reliability which is
 what's being discussed here).
 
 It's easy to see how this assertion of yours is totally wrong in many
 ways...
 
 Example 1: a toy system made up of subsystem A (which has a probability
 of 90% of working right) whose output feeds into subsystem B (which has
 a probability of 80% of working right).  A's failures and B's faliures
 are statistically independent (no common-mode failures, c).
 
 The ``level of goodness'' (probability of working right) of the weakest
 component, B, is 80%; but the whole system has a ``level of goodness''
 (probability of working right) of just 72%, since BOTH subsystems must
 work right for the whole system to do so.  72 != 80 and thus your
 assertion is false.
 
 More generally: subsystems in series with independent failures can
 produce a system that's weaker than its weakest component.
 
 
 Example 2: another toy system made up of subsystems A1, A2 and A3, each
 trying to transform the same input supplied to all of them into a 1 bit
 result; each of these systems works right 80% of the time, statistically
 independently (no common-mode failures, c).  The three subsystems'
 results are reconciled by a simple majority-voting component M which
 emits as the system's result the bit value that's given by two out of
 three of the Ai subsystems (or, of course, the value given unanimously
 by all) and has extremely high reliability thanks to its utter
 simplicity (say 99.9%, high enough that we can ignore M's contribution
 to system failures in a first-order analysis).
 
 The whole system will fail when all Ai fail together (probability
 0.2**3) or when 2 out of them fail while the hird one is working
 (probability 3*0.8*0.2**2):
 
 0.2**3+3*0.2**2*0.8
 0.10404
 
 So, the system as a whole has a level of goodness (probability of
 working right) of almost 90% -- again different from the weakest
 component (each of the three Ai's), in this case higher.
 
 More generally: subsystems in parallel (arranged so as to be able to
 survive the failure of some subset) with indipendent failures can
 produce a system that's stronger than its weakest component.
 
 
 Even in the field of security, which (changing the subject...) you
 specifically refer to, similar considerations apply.  If your assertion
 was correct, then removing one component would never WEAKEN a system's
 security -- it might increase it if it was the weakest, otherwise it
 would leave it intact.  And yet, a strong and sound tradition in
 security is to require MULTIPLE components to be all satisfied e.g. for
 access to secret information: e.g. the one wanting access must prove
 their identity (say by retinal scan), possess a physical token (say a
 key) AND know a certain secret (say a password).  Do you really think
 that, e.g., removing the need for the retinal scan would make the
 system's security *STRONGER*...?  It would clearly weaken it, as a
 would-be breaker would now need only to purloin the key and trick the
 secret password out of the individual knowing it, without the further
 problem of falsifying a retinal scan successfully.  Again, such security
 systems exist and are traditional exactly because they're STRONGER than
 their weakest component!
 
 
 So, the implication accompanying your assertion, that strenghtening a
 component that's not the weakest one is useless, is also false.  It may
 indeed have extremely low returns on investment, depending on system's
 structure and exact circumstances, but then again, it may not; nothing
 can be inferred about this ROI issue from the consideration in question.
 
 
 Alex

You win the argument, and thanks you prove my point. You typically
concerned yourself with the technical part of the matter, yet you
completely ignored the point I was trying to make.
That is that in real world applications formally proving the application
is not only an enormous resource waster but it also pays very little if
at all. I think most cases will fall under point (1) of your post, and
as so many other not formally proven subsystems are at work at the same
time there will be hardly any gain in doing it.
Point (2) of your post would be my preferred solution, and what is
usually done in hardware.
In the third part of your post, regarding security, I think you went off
the road. The weakest component would not be one of the requisites of
access, the weakest component I was referring to would be an actual
APPLICATION, e.g. an ftp server. In that case, if you have several
applications running your security will be the security of the weakest
of them.






-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Carl Banks
On Sat, 01 Sep 2007 08:38:38 -0300, Jorge Godoy wrote:

 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? 

The word I used was comparable.

 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 misunderstanding of your was bugging me.

Well, I wasn't talking about importance, actually.  Importance is 
really a matter for sociologists.  Perhaps you can find a sociologist who 
would agree that a health monitoring system is more important than an 
aircraft control system (probably wouldn't be too hard, actually, 
especially if it's a military aircraft).  I could hardly argue with that.

But, frankly, importance to society is only a small part of what 
determines criticalness of the application; and criticalness is what 
factors into a decision on what programming language to use.  Here are 
some of the main factors that determine criticalness:

How much time is there between failure and catastrophe?  What is the cost 
(societal and/or economic) of a catastrophe?  How recoverable is a 
failure?  What is the degree of difficulty of the programming?  Do small 
errors accumulate?  How many government regulations does the code have to 
meet?  What is the acceptable failure rate before an application is 
allowed to deploy?  How much money is being spent to ensure flawless 
operation before it even deploys?

By these criteria, Google web search, your health monitoring system, a 
bank transaction system, etc., hardly compare to something like aircraft 
control.  I'm sorry.


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

Cool. Not that, by itself, would be enough to make me feel good about 
Python on airplanes.


 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.

Really?  I must work with crazy people then, because we are working on a 
full authority control system: no bypassing the computer, no manual 
intervention.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Carl Banks
On Sat, 01 Sep 2007 17:19:49 +0200, Pierre Hanser wrote:

 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.

But they had electronic (analog) systems that were (supposedly) just as 
heavily regulated and scrutinized as the digital computers of today; and 
were a lot more scrutinized than, say, the digital computers that banks 
were using.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Alex Martelli
Ricardo Aráoz [EMAIL PROTECTED] wrote:
   ...
  We should remember that the level
  of security of a 'System' is the same as the level of security of it's
  weakest component,
   ...
 You win the argument, and thanks you prove my point. You typically
 concerned yourself with the technical part of the matter, yet you
 completely ignored the point I was trying to make.

That's because I don't particularly care about the point you were
trying to make (either for or against -- as I said, it's a case of ROI
for different investments [in either security, or, more germanely to
this thread, reliability] rather than of useful/useless classification
of the investments), while I care deeply about proper system thinking
(which you keep failing badly on, even in this post).

 In the third part of your post, regarding security, I think you went off
 the road. The weakest component would not be one of the requisites of
 access, the weakest component I was referring to would be an actual
 APPLICATION,

Again, F- at system thinking: a system's components are NOT just
applications (what's the alternative to their being actual, btw?),
nor is it necessarily likely that an application would be the weakest
one of the system's components (these wrong assertions are in addition
to your original error, which you keep repeating afterwards).

For example, in a system where access is gained *just* by knowing a
secret (e.g., a password), the weakest component is quite likely to be
that handy but very weak architectural choice -- or, seen from another
viewpoint, the human beings that are supposed to know that password,
remember, and keep it secret.  If you let them choose their password,
it's too likely to be fred or other easily guessable short word; if
you force them to make it at least 8 characters long, it's too likely to
be fredfred; if you force them to use length, mixed case and digits,
it's too likely to be Fred2Fred.  If you therefore decide that
passwords chosen by humans are too weak and generate one for them,
obtaining, say, FmZACc2eZL, they'll write it down (perhaps on a
post-it attached to their screen...) because they just can't commit to
memory a lot of long really-random strings (and nowadays the poor users
are all too likely to need to memorize far too many passwords).  A
clever attacker has many other ways to try to steal passwords, from
social engineering (pose as a repair person and ask the user to reveal
their password as a prerequisite of obtaining service), to keystroke
sniffers of several sorts, fake applications that imitate real ones and
steal the password before delegating to the real apps, etc, etc.

Similarly, if all that's needed is a physical token (say, some sort of
electronic key), that's relatively easy to purloin by traditional means,
such as pickpocketing and breaking-and-entering; certain kind of
electronic keys (such as the passive unencrypted RFID chips that are
often used e.g. to control access to buildings) are, in addition,
trivially easy to steal by other (technological) means.

Refusing to admit that certain components of a system ARE actually part
of the system is weak, blinkered thinking that just can't allow halfway
decent system design -- be that for purposes of reliability, security,
availability, or whatever else.  Indeed, if certain part of the system's
architecture are OUTSIDE your control (because you can't redesign the
human mind, for example;-), all the more important then to make them the
focus of the whole design (since you must design AROUND them, and any
amelioration of their weaknesses is likely to have great ROI -- e.g., if
you can make the users take a 30-minutes short course in password
security, and accompany that with a password generator that makes
reasonably memorable though random ones, you're going to get substantial
returns on investment in any password-using system's security).

 e.g. an ftp server. In that case, if you have several
 applications running your security will be the security of the weakest
 of them.

Again, false as usual, and for the same reason I already explained: if
your system can be broken by breaking any one of several components,
then it's generally WEAKER than the weakest of the components.  Say that
you're running on the system two servers, an FTP one that can be broken
into by 800 hackers in the world, and a SSH one that can only be broken
into by 300 hackers in the world; unless every single one of the hackers
who are able to break into the SSH server is *also* able to break into
the FTP one (a very special case indeed!), there are now *MORE* than 800
hackers in the world that can break into your system as a whole -- in
other words, again and no matter how often you repeat falsities to the
contraries without a shred of supporting argument, your assertion is
*FALSE*, and in this case your security is *WEAKER* than the security of
the weaker of the two components.

I do not really much care what point(s) you are trying to make through
your 

Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Russ
On Sep 1, 4:25 am, Bryan Olson

 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.


Excellent points. As for no strong case for adding new features to
Python specifically for design-by-contract, if you mean adding
something to language itself, I agree, but I see nothing wrong with
adding it to the standard libraries, if that is possible without
changing the language itself. Someone please correct me if I am wrong,
but I think PEP adds only to the libraries.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Russ
On Sep 1, 6:51 pm, [EMAIL PROTECTED] (Alex Martelli)

 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 suppose if I want it badly enough, I will. But I also happen to be a
bit obsessive about the appearance of my code, and this does
complicate it a bit. The nice thing about having it in the doc string
(as per PEP 316) is that, while it is inside the function, it is also
separate from the actual code in the function. I like that. As far as
I am concerned, the self-test code shouldn't be tangled up with the
primary code.

By the way, I would like to make a few comments about the
reliability of Python code. Apparently I offended you the other day
by claiming or implying that Python code is inherently unreliable. I
think it is probably possible to write very reliable code in Python,
particularly for small to medium sized applications, but you probably
need top notch software engineers to do it. And analyzing code or
*proving* that a program is correct is technically harder without
static typing. In highly regulated safety critical domains, you need
more than just reliable code; you need to *demonstrate* or *prove* the
reliability somehow.

I personally use Python for its clean syntax and its productivity with
my time, so I am certainly not denigrating it. For the RD 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).

In any case, when you get right down to it, I probably don't know what
the hell I'm talking about anyway, so I will bring this rambling to a
merciful end.

On, one more thing. I see that the line wrapping on Google Groups is
finally working for me after many months. Fantastic! I can't help but
wonder if my mentioning it to you a few days ago had anything to do
with it.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Michele Simionato
On Sep 2, 7:05 am, Russ [EMAIL PROTECTED] wrote:
 Someone please correct me if I am wrong,
 but I think PEP adds only to the libraries.

You are wrong, PEPs also add to the core language. Why don't you give
a look
at the PEP parade on python.org?

Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-09-01 Thread Russ
On Sep 1, 10:44 pm, Russ [EMAIL PROTECTED] wrote:

 On, one more thing. I see that the line wrapping on Google Groups is
 finally working for me after many months. Fantastic! I can't help but
 wonder if my mentioning it to you a few days ago had anything to do
 with it.

Well, it's working on the input side anyway.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

 Python really isn't suitable for in-flight controls  for various
 reasons, and mission critical concerns is a minor one (systems with

Do you know anything about the FAA certification process for flight-
critical systems? I am not an expert on it, but I know it is very
expensive. If I am not mistaken, getting such code certified is more
expensive than developing it in the first place. Why would that be so
if, as you claim, mission critical concerns is a minor one?

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Carl Banks
On Fri, 31 Aug 2007 01:15:04 -0400, Roy Smith wrote:

 Carl Banks [EMAIL PROTECTED] wrote:
 Python really isn't suitable for in-flight controls for various
 reasons, and mission critical concerns is a minor one (systems with
 less underlying complexity tend to have fewer failure modes).  But
 mostly it's raw throughput: Python is just too slow.  Flight control
 computers have to be powerful enough make a ton of mathematical
 calculations in a matter of milliseconds, and under strict weight and
 power constraints.  The cost of running 100 times slower than optimal
 is just too high.
 
 I'm not convinced that's true for all avionics uses.

Of course it's not.  I was talking about flight control, not avionics in 
general.  (Perhaps when single-engine Cessnas go digital we'll even see 
flight controllers in Python.)


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ
On Aug 30, 7:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
 Russ [EMAIL PROTECTED] wrote:

...

  programs. Any idea how much Python is used for flight control systems
  in commercial
  transport aircraft or jet fighters?


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 will take issue with some of your remarks,
bit none of it is intended to be personal, and I sincerely hope
you don't take it that way.


 Are there differences in reliability requirements between the parts of
 such control systems that run on aircraft themselves, and those that run
 in airports' control towers?  Because Python *IS* used in the latter
 case, cfr http://www.python.org/about/success/frequentis/ ... if
 on-plane control SW requires hard-real-time response, that might be a
 more credible reason why Python would be inappropriate (any garbage
 collected language is NOT a candidate for hard-real-time SW!) than your
 implied aspersions against Python's reliability.


I've seen that site before. They have a nice product
that was developed in Python, but it is not clear to me
that is actually safety-critical. It appears to be a
GUI designer for displays at air traffic control towers.
I can't tell if this is just a development tool, or if it
the python-based product is actually used directly by
controllers. Also, this product does not seem to actually
display aircraft to controllers. It seems to be more of
a semi-static display of runway conditions. Not to
minimize its importance, but I don't know if this product
actually qualifies as safety critical, and if it does,
it probably does so only marginally.


 According to
 http://uptime.pingdom.com/site/month_summary/site_name/www.google.com,
 Google's current uptime is around 99.99%, with many months at 100% and a
 few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW,
 and in real-world conditions where power can go away, network cables can
 accidentally get cut, etc.  I'm Uber Tech Lead for Production Systems at
 Google -- i.e., the groups I uber-lead are responsible for some software
 which (partly by automating things as much as possible) empowers our
 wondrous Site Reliability Engineers and network specialists to achieve
 that uptime in face of all the Bad Stuff the world can and does throw at
 us.  Guess what programming language I'm a well-known expert of...?


I certainly cannot deny the success of Google, but I
don't think that a high uptime with thousands of servers
is comparable to reliable safety-critical software. You
can't put thousands of flight management computers on
an airplane and just switch over to another as they go
fail. And if a web server gives bogus results nobody
worries much, but if a flight computer gives bogus
outputs, some people worry a lot.

By the way, I use Google Groups, and it has a few
annoying glitches. For example, I couldn't read your
post without scrolling horizontally. With all the money
and manpower at Google's disposal, couldn't you fix that
problem? Another problem I have had for months is that
when I write a message to post, I get no auto scrolling,
so I have to add manual line breaks to keep the text from
running out of the window -- then the reader sees all
those ugly misplaced line breaks in the output. These are
just annoyances, but why hasn't Google fixed them yet?

The point I am trying to make is that, while Google does
great things, and is very successful commercially, the
quality of its code could certainly use some improvement.
Microsoft is also very successful commercially, but
certainly you wouldn't argue that is is a result of the
quality of its software, I hope.

I may have a simplistic view, but I have always thought
that the requirements of most Google code are the very
antithesis of the requirements of safety critical code.
When I do a search, I
fully expect most of the results to be crap. It's a
scattershot approach. If I get one good result, I am
usually happy. Safety critical software is exactly the
opposite: if you get one *bad* result, you could be in
a heap of something nasty.



  The important question is this: why do I waste my time with bozos like
  you?

 Yeah, good question indeed, and I'm asking myself that -- somebody who
 posts to this group in order to attack the reliability of the language
 the group is about (and appears to be supremely ignorant about its use


I am sorry that you took offense at my pointing out the
weaknesses of Python. It's a great language for certain
kinds of applications, but it is not necessarily
appropriate for everything. I am personally using it for
prototyping a safety critical system that, if it is
ultimately fielded, will affect the safety of
millions of people, including you. However, my Python
prototype is for research and design purposes. The
ultimate 

Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Carl Banks
On Thu, 30 Aug 2007 22:56:54 -0700, Russ wrote:

 Python really isn't suitable for in-flight controls  for various
 reasons, and mission critical concerns is a minor one (systems with
 
 Do you know anything about the FAA certification process for flight-
 critical systems? I am not an expert on it, but I know it is very
 expensive. If I am not mistaken, getting such code certified is more
 expensive than developing it in the first place. Why would that be so
 if, as you claim, mission critical concerns is a minor one?

I made no such claim; you misconstrued what I wrote.  I wrote that 
mission critical concerns are a minor reason why Python is not used, not 
that mission critical concerns were minor.

As a matter of fact, FAA cert is a major pain, and they unit test the 
hell out of everything.  I'm not aware of any reason why Python couldn't 
be certified if it passed the tests, but it likely wouldn't pass as 
easily as a compiled language.  OTOH, spiffy features like design-by-
contract aren't going to improve your chances of getting FAA cert, either.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Bruno Desthuilliers
Russ a écrit :
 Pre and post conditions applying to the class ? Now that's an
 interesting concept. IIRC, Eiffels pre and post conditions only apply to
 methods, and I fail to see how they could apply to a class. But since
 you're an expert on the subject, I don't doubt you'll enlighten us ?
 
 I made a simple mistake. Excuse me. Oh wait ... aren't you one of the
 sensitivity police who
 laid into me for criticizing someone else. 

Nope, I'm one of the regular citizens here that tried to make you 
realize you were acting as an arrogant clueless newbie.

 For the record, the guy I
 criticized
 made ridiculous assertions about DBC.

For the record, the guy you treaded as he was a retarted knows much more 
than you about both Python and DbC. Thinking that someone is ignorant 
or ridiculous because he does not happen to share your opinions on 
some subject is certainly not what's I'd call an intelligent, civilized, 
  respectful attitude.

  All I did was to make a simple
 mistake about
 an inconsequential matter.

All you did was persisting on being arrogant while showing your lack of 
knowledge on both Python and DbC.

 No, pre and post conditions obviously don't
 apply to classes,
 but all I said was that that's how it appeared to me at first
 glance.
 
 If you are upset about my criticism of one of your colleagues, please
 tell him to quite making
 outrageous assertions about something he obviously knows little about.
 

I'm not upset. I'm actually trying to help you realizing the dumbness of 
your attitude. But I'm afraid this is going to be a lost cause...
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Bruno Desthuilliers
Russ a écrit :
 FWIW, the Eiffel and SPARK Ada folks also brilliantly 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Michele Simionato
On Aug 31, 10:02 am, Russ [EMAIL PROTECTED] wrote:

 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 [EMAIL PROTECTED] wrote:
 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Paul Rubin
[EMAIL PROTECTED] (Alex Martelli) writes:
 Yeah, good question indeed, and I'm asking myself that -- somebody who
 posts to this group in order to attack the reliability of the language
 the group is about (and appears to be supremely ignorant about its use
 in air-traffic control and for high-reliability mission-critical
 applications such as Google's Production Systems software) might well
 be considered not worth responding to.  OTOH, you _did_ irritate me
 enough that I feel happier for venting in response;-)

Hi Alex, I'm a little confused: does Production Systems mean stuff
like the Google search engine, which (as you described further up in
your message) achieves its reliability at least partly by massive
redundancy and failover when something breaks?  In that case why is it
so important that the software be highly reliable?  Is a software
fault really worse than a hardware fault, especially if it's
permissible to sometimes let a transaction (like a search query) go
uncompleted (e.g. by displaying a try again later message)?  If you
get 1 billion queries in a month and a half dozen of them don't
complete (e.g. they give empty or incorrect results when there are
some good hits they should display) but the server is never actually
down, can you still claim 100% uptime?

There's a philosophy in Erlang described as let it crash,
i.e. programmers are told NOT to program defensively such as by
checking inputs for validity.  Instead they should just rely on the
fault tolerance and process restart stuff to get things going again if
their process fails.  Similarly if the Google search software hits
some fatal condition once in a while, maybe it's enough to just treat
it as a crashed box and let the failover mechanisms handle the
problem.  Of course then there's a second level system to manage the
restarts that has to be very reliable, but it doesn't have to deal
with much weird concocted input the way that a public-facing internet
application has to.

Therefore I think Russ's point stands, that we're talking about a
different sort of reliability in these highly redundant systems, than
in the systems Russ is describing.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Paul Rubin
Michele Simionato [EMAIL PROTECTED] writes:
  http://archive.eiffel.com/doc/manuals/technology/contract/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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Ricardo Aráoz
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.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Paul Rubin
Ricardo Aráoz [EMAIL PROTECTED] writes:
 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-assurance-floss.html

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Neil Cerutti
On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Alex Martelli
Paul Rubin http://[EMAIL PROTECTED] wrote:
   ...
 Hi Alex, I'm a little confused: does Production Systems mean stuff
 like the Google search engine, which (as you described further up in
 your message) achieves its reliability at least partly by massive
 redundancy and failover when something breaks?

The infrastructure supporting that engine (and other things), yes.

  In that case why is it
 so important that the software be highly reliable?  Is a software

Think common-mode failures: if a program has a bug, so do all
identical copies of that program.  Redundancy works for cheap hardware
because the latter's unreliability is essentially free of common-mode
failures (when properly deployed): it wouldn't work against a design
mistake in the hardware units.  Think of the famous Pentium division
bug: no matter how many redundant but identical such buggy CPUs you
place in parallel to compute divisions, in the error cases they'll all
produce the same wrong results.  Software bugs generally work (or,
rather, fail to work;-) similarly to hardware design bugs.

There are (for both hw and sw) also classes of mistakes that don't quite
behave that way -- occasional glitches that are not necessarily
repeatable and are heavily state-dependent (race conditions in buggy
multitasking SW, for example; and many more examples for HW, where flaky
behavior may be triggered by, say, temperature situations).  Here, from
a systems viewpoint, you might have a system that _usually_ says that
10/2 is 5, but once in a while says it's 4 instead (as opposed to the
Pentium division bug case where it would always say 4) -- this is much
more likely to be caused by flaky HW, but might possibly be caused by
the SW running on it (or the microcode in between -- not that it makes
much of a difference one way or another from a systems viewpoint).

Catching such issues can, again, benefit from redundancy (and
monitoring, watchdog systems, health and sanity checks running in the
background, c).  Quis custodiet custodes is an interesting problem
here, since bugs or flakiness in the monitoring/watchdog infrastructure
have the potential to do substantial global harm; one approach is to
invest in giving that infrastructure an order of magnitude more
reliability than the systems it's overseeing (for example by using more
massive and *simple* redundancy, and extremely straightforward
architectures).  There's ample literature in the matter, but it
absolutely needs a *systems* approach: focusing just on the HW, just on
the SW, or just on the microcode in-between;-), just can't help much.

 some good hits they should display) but the server is never actually
 down, can you still claim 100% uptime?

I've claimed nothing (since all such measurements and methodologies
would no doubt be considered confidential unless and until cleared for
publication -- this has been done for a few whitepapers about some
aspects of Google's systems, but never to the best of my knowledge for
the metasystem as a whole), but rather pointed to
http://uptime.pingdom.com/site/month_summary/site_name/www.google.com,
a publically available site which does publish its methodology (at
http://uptime.pingdom.com/general/methodology); summarizing, as they
have no way to check that the results are right for the many sites
they keep an eye on, they rely on the HTTP result codes (as well as
validity of HTTP headers returned, and of course whether the site does
return a response at all).

 problem.  Of course then there's a second level system to manage the
 restarts that has to be very reliable, but it doesn't have to deal
 with much weird concocted input the way that a public-facing internet
 application has to.

Indeed, Production Systems' software does *not* have to deal with
input from the general public -- it's infrastructure, not user-facing
applications (except in as much as the users are Google engineers or
operators, say).  IOW, it's *exactly* the code that has to be very
reliable (nice to see that we agree on this;-), and therefore, if as
you then said Russ's point stands, would NOT be in Python -- but it
is. So, I disagree about the standing status of his so-called point.
 
 Therefore I think Russ's point stands, that we're talking about a
 different sort of reliability in these highly redundant systems, than
 in the systems Russ is describing.

Russ specifically mentioned *mission-critical applications* as being
outside of Python's possibilities; yet search IS mission critical to
Google.  Yes, reliability is obtained via a systems approach,
considering HW, microcode, SW, and other issues yet such as power
supplies, cooling units, network cables, etc, not as a single opaque big
box but as an articulated, extremely complex and large system that needs
testing, monitoring, watchdogging, etc, at many levels -- there is no
other real way to make systems reliable (you can't do it by just looking
at components in isolation).  Note that this does have costs and
therefore it needs to be 

Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Alex Martelli
Michele Simionato [EMAIL PROTECTED] wrote:
   ...
 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.org/wiki/List_of_Google_products for an overview,
http://searchengineland.com/070220-091136.php for 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Steve Holden
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 -

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

Alex Martelli wrote:

 Russ specifically mentioned *mission-critical applications* as being
 outside of Python's possibilities; yet search IS mission critical to
 Google.  Yes, reliability is obtained via a systems approach,

Alex, I think you are missing the point. Yes, I'm sure that web
searches are critical to
Google's mission and commercial success. But the point is that a few
subtle bugs cannot
destroy Google. If your search engines and associated systems have
bugs, you fix them
(or simply tolerate them) and continue on. And if a user does not get
the results he wants,
he isn't likely to die over it -- or even care much.

Online financial transactions are another matter altogether, of
course. User won't die, but
they will get very irate if they lose money. But I don't think that's
what you are talking about
here.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Steve Holden
Russ wrote:
 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?
 
You aren't, and if I wasn't being even-handed I apologize.

 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.
 
Well that's a healthy attitude, but I am concerned that the Python 
community should be as welcoming as possible, so I don't like the fact 
that you feel you are being treated differently from anyone else.

 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.
 
It does constrain functions to return only from the bottom of their 
code, though, which not all Python functions currently do. Though 
there's nothing to stop you putting the calls before every return.

 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.
 
That would be a sensible suggestion. It would also be possible to guard 
the lengthier tests with if debug to allow them to be omitted 
(presumably along with their imports with a little further effort in 
code organization) in (optimized) production mode where timings were 
critical.

This could allow the benefits of DbC and unit testing at the same time.

Putting the verification code into external functions does assume that 
global variables aren't used in the pre- and post-conditions, but I 
presume that's a part of the regime anyway.

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 -

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

Neil Cerutti wrote:

 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?

The idea here is that errors in the self-testing code are unlikely to
be correlated with
errors in the primary code. Hence, you get a sort of multiplying
effect on reliability. For
example, if the chance of error in the primary code and the self-test
code are each 0.01,
the chance of an undetected error is approximately 0.01^2 or 0.0001.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

Steve Holden wrote:

 Well that's a healthy attitude, but I am concerned that the Python
 community should be as welcoming as possible, so I don't like the fact
 that you feel you are being treated differently from anyone else.

I certainly appreciate that. And I will try my best to refrain from
the little personal zingers (and
the big ones too).

  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.
 
 It does constrain functions to return only from the bottom of their
 code, though, which not all Python functions currently do. Though
 there's nothing to stop you putting the calls before every return.

Oops! I didn't think of that. The idea of putting one before every
return certainly doesn't
appeal to me. So much for that idea.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Ricardo Aráoz
Neil Cerutti wrote:
 On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote:
 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?
 

Actually my point was that if a program is to be trusted in a critical
situation (critical as in catastrophe if it goes wrong) then the OS, the
 compiler/interpreter etc should abide by the same rules. That is
obviously not possible, so there's not much case in making the time
investment necessary for correctness proof of a little program (or
usually a little function inside a program) when the possibilities for
failure are all around it and even in the code that will run that
function. And we should resort to other more sensible answers to the
safety problem.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Jorge Godoy
Russ wrote:

 Alex, I think you are missing the point. Yes, I'm sure that web
 searches are critical to
 Google's mission and commercial success. But the point is that a few
 subtle bugs cannot
 destroy Google. If your search engines and associated systems have
 bugs, you fix them
 (or simply tolerate them) and continue on. And if a user does not get
 the results he wants,
 he isn't likely to die over it -- or even care much.

But if this pattern of not getting wanted results is common, then the user
will migrate to alternative search engines and this will *kill* the
business.  Wrong results won't impact ONE search, but many will impact the
company business and will be part of the recipe to take it out of business. 

 Online financial transactions are another matter altogether, of
 course. User won't die, but
 they will get very irate if they lose money. But I don't think that's
 what you are talking about
 here.

Lets make someone loose his job and have all his money commitments
compromised because of this money lost and we might be talking about people
taking their lives.

Again, this isn't 100% sure to happen, but it *can* happen.  

As it happens with a peacemaker: the user won't die if his heart skips one
beat, but start skipping a series of them and you're incurring in serious
problems.

Just because the result isn't immediate it doesn't mean it isn't critical.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ

Ricardo Aráoz wrote:

 Actually my point was that if a program is to be trusted in a critical
 situation (critical as in catastrophe if it goes wrong) then the OS, the
  compiler/interpreter etc should abide by the same rules. That is
 obviously not possible, so there's not much case in making the time
 investment necessary for correctness proof of a little program (or
 usually a little function inside a program) when the possibilities for
 failure are all around it and even in the code that will run that
 function. And we should resort to other more sensible answers to the
 safety problem.

I don't quite see it that way.

I would agree that if your OS and compiler are unreliable, then it
doesn't make much sense to bend over backwards worrying about the
reliability of your
application. But for real safety-critical applications, you have no
excuse for not using a
highly reliable OS and compiler. For really critical stuff, I think
the real-time OSs are usually
stripped down to
the bare basics. And if you are using something like SPARK Ada, the
language itself is
stripped of many of the fancier features in Ada itself. (There's also
something called the
Ada Ravenscar profile, which I believe is geared for safety-critical
use but is not quite as
restrictive as SPARK.)

Keep in mind that the OS and compiler are typically also
used for many other applications, so they tend to get tested fairly
thoroughly. And remember
also that you won't have extraneous applications running -- like a web
browser
or a video game, so the OS will probably not be heavily stressed. The
most likely source
of failure is likely to be your application, so bending over backwards
to get it right makes
sense.

Then again, if you are running C on Windows, you might as well just
give up on reliability
from the start. You don't have a prayer.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Steve Holden
Jorge Godoy wrote:
 Russ wrote:
 
 Alex, I think you are missing the point. Yes, I'm sure that web
 searches are critical to
 Google's mission and commercial success. But the point is that a few
 subtle bugs cannot
 destroy Google. If your search engines and associated systems have
 bugs, you fix them
 (or simply tolerate them) and continue on. And if a user does not get
 the results he wants,
 he isn't likely to die over it -- or even care much.
 
 But if this pattern of not getting wanted results is common, then the user
 will migrate to alternative search engines and this will *kill* the
 business.  Wrong results won't impact ONE search, but many will impact the
 company business and will be part of the recipe to take it out of business. 
 
 Online financial transactions are another matter altogether, of
 course. User won't die, but
 they will get very irate if they lose money. But I don't think that's
 what you are talking about
 here.
 
 Lets make someone loose his job and have all his money commitments
 compromised because of this money lost and we might be talking about people
 taking their lives.
 
 Again, this isn't 100% sure to happen, but it *can* happen.  
 
 As it happens with a peacemaker: the user won't die if his heart skips one
 beat, but start skipping a series of them and you're incurring in serious
 problems.
 
 Just because the result isn't immediate it doesn't mean it isn't critical.
 
 
We probably need to distinguish between mission-critical, where a 
program has to work reliably for an organization to meet its goals, and 
safety-critical where people die or get hurt if the program misbehaves.

The latter are the ones where you need to employ all possible techniques 
to avoid all possible failure modes.

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 -

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-31 Thread Russ
On Aug 31, 6:45 pm, Steve Holden

 We probably need to distinguish between mission-critical, where a
 program has to work reliably for an organization to meet its goals, and
 safety-critical where people die or get hurt if the program misbehaves.

The term mission critical itself can have a wide range of
connotations.

If a software failure would force a military pilot to abort his
mission and hobble back home with a partially disabled aircraft,
that's what I think of as mission critical software.

If Google needs reliable software on its servers to maintain its
revenue stream, that's another kind of mission critical software,
but the criticality is certainly less immediate in that case.

In the first case, the software glitch definitely causes mission
failure. In the Google case, the software problems *may* ultimately
cause mission failure, but probably only if nothing is done for quite
some time to rectify the situation. If that is the case, then the
software itself is not the critical factor unless it cannot be
corrected and made to function properly in a reasonable amount of time.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 I disagree. IMO automatic testing is thousands of times better than
 design by contract and Python has already all the support you need
 (unittest, doctest, py.test, nose, ...)

In theory, anything you can verify with design by contract you can
also verify with unittest and the rest. However, design by contract
has a major practical advantage: if you have real (or simulated)
inputs available, you don't need to write a test driver or generate
test inputs for each class or function.

All you need to do is to run your program with the real (or simulated)
inputs, all the internal data that gets passed around between classes
and functions gets generated as usual, and everything gets tested
automatically. In other words, you are spared the potentially
considerable effort of generating and storing samples of all the
internal data that gets passed around internally.

You may want to do unit tests also, of course. Separate unit tests
will give you more control and allow you to test individual classes
and functions using a wider variety of inputs. But if your design by
contract is comprehensive (i.e., passing it guarantees correct
functioning of your code), then your unit tests can simply make use of
the tests already available in the design by contract. So you've done
no extra work in setting up the design by contract anyway.

Another significant advantage of design by contract is that the
tests are all right there in your source code, where they are much
less likely to get lost or ignored by subsequent programmers who need
to maintain the code.  Relying on separate units tests is a bit like
relying on extended comments or design documents that are separate
from the code. Yes, those are certainly useful, but they do not
eliminate the need for comments in the code.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Chris Mellon
On 8/29/07, Russ [EMAIL PROTECTED] wrote:

  But it's always a good idea to make your software correct and as
  reliable as possible, isn't it? The problem is the external constraints
  on the project. As the old saying goes: Cheap, fast, reliable: choose
  any two.

 If you are suggesting that programming by contract is not
 appropriate for every application, you will get no argument from me.
 All I am suggesting is that having the option to use it when you need
 it is very desirable, and it can possibly enhance the versatility of
 Python by making Python more suitable for *some* mission-critical
 applications.


PEP 316 introduces new syntax for a limited use feature. That's pretty
much a no-starter, in my opinion, and past experience tends to bear
that out. Furthermore, it predates decorators  and context managers,
which give all the syntax support you need and let you move the actual
DBC features into a library. I can't remember if I mentioned this
before but I believe that Philip Ebys PEAK toolkit has some stuff you
could use for DBC.

 I once read a book on something called SPARK Ada, which also supports
 programming by contract. I was pleasantly surprised to discover
 yesterday that support for the such methods is also available for
 Python. However, the support would obviously be a bit stronger if it
 were in the core Python distribution.


If a well written contract library were to exist, and people were to
use it, and the author were interested, it would make a decent
candidate for inclusion in the standard library, and I wouldn't oppose
such a thing (for all my opinion is worth, ie essentially nothing).
The PEP 316 special syntax is another matter entirely.

The best way for this to happen is for you to find or write such a
library, and use it to write good code.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 PEP 316 introduces new syntax for a limited use feature. That's pretty
 much a no-starter, in my opinion, and past experience tends to bear
 that out. Furthermore, it predates decorators  and context managers,
 which give all the syntax support you need and let you move the actual
 DBC features into a library. I can't remember if I mentioned this
 before but I believe that Philip Ebys PEAK toolkit has some stuff you
 could use for DBC.

I don't see how you can avoid adding some new syntax, given that
Python does not
currently have syntax for specifying invariants and pre- and post-
conditions. And if I am
not mistaken, the new syntax would appear only in doc strings, not in
the regular Python
code itself. We're not really talking here about changing the core
Python syntax itself,
so I don't see it as a non-starter. Anyone who chooses not to use
would be completely
unaffected.

As far as I can tell, Terence Way has done a nice job of implementing
design by contract for
Python, but perhaps a better approach is possible. The advantage of
making part of the
core Python distribution is that it would get vetted more thoroughly.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Chris Mellon
On 8/30/07, Russ [EMAIL PROTECTED] wrote:

  PEP 316 introduces new syntax for a limited use feature. That's pretty
  much a no-starter, in my opinion, and past experience tends to bear
  that out. Furthermore, it predates decorators  and context managers,
  which give all the syntax support you need and let you move the actual
  DBC features into a library. I can't remember if I mentioned this
  before but I believe that Philip Ebys PEAK toolkit has some stuff you
  could use for DBC.

 I don't see how you can avoid adding some new syntax, given that
 Python does not
 currently have syntax for specifying invariants and pre- and post-
 conditions. And if I am
 not mistaken, the new syntax would appear only in doc strings, not in
 the regular Python
 code itself. We're not really talking here about changing the core
 Python syntax itself,
 so I don't see it as a non-starter. Anyone who chooses not to use
 would be completely
 unaffected.


I misread the pep as adding the identifiers into the actual python
syntax, not in the docstring. All the more reason to implement it as a
library, then. I actually think that decorators and context managers
would be nicer than special docstring syntax, but I recognize the
benefit of the doctest style approach.

 As far as I can tell, Terence Way has done a nice job of implementing
 design by contract for
 Python, but perhaps a better approach is possible. The advantage of
 making part of the
 core Python distribution is that it would get vetted more thoroughly.


Things get vetted *before* they get added to the core, not after.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 Things get vetted *before* they get added to the core, not after.

I realize that. I meant that it would get vetted in the process of
putting it into the core. That
would provide more confidence that it was done the best possible way
-- or close to it.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Bruno Desthuilliers
Russ a écrit :
(snip)

 I don't see how you can avoid adding some new syntax, given that
 Python does not
 currently have syntax for specifying invariants and pre- and post-
 conditions. 

class Parrot(object):
   @pre(lambda x : x != 42)
   @post(lambda result: result != 42)
   @invariant(lambda self: self.x == 42)
   def reliable_method(self, x):
 # your code here
 return something

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Bruno Desthuilliers
Russ a écrit :
 On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
 wrote:
 
 
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.
 
 
 I get the strong impression you don't really understand what
 programming by contract is.

I get the strong impression you don't really understand how 
condescending you are.

 I have not yet personally used it,

You have no working experience with the concept, but you think it should 
make it into Python's core ???
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

Bruno Desthuilliers wrote:
 Russ a écrit :
 (snip)

  I don't see how you can avoid adding some new syntax, given that
  Python does not
  currently have syntax for specifying invariants and pre- and post-
  conditions.

 class Parrot(object):
@pre(lambda x : x != 42)
@post(lambda result: result != 42)
@invariant(lambda self: self.x == 42)
def reliable_method(self, x):
  # your code here
  return something

That looks like new syntax to me. Did I miss your point?

I have no strong leaning about what the exact syntax should be for
programming by contract.
The syntax you show above seems reasonable, except that I am not sure
about requiring
that everything be put inside parentheses. That seems a bit confining
for more complex
conditions.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Chris Mellon
On 8/30/07, Russ [EMAIL PROTECTED] wrote:

 Bruno Desthuilliers wrote:
  Russ a écrit :
  (snip)
 
   I don't see how you can avoid adding some new syntax, given that
   Python does not
   currently have syntax for specifying invariants and pre- and post-
   conditions.
 
  class Parrot(object):
 @pre(lambda x : x != 42)
 @post(lambda result: result != 42)
 @invariant(lambda self: self.x == 42)
 def reliable_method(self, x):
   # your code here
   return something

 That looks like new syntax to me. Did I miss your point?

 I have no strong leaning about what the exact syntax should be for
 programming by contract.
 The syntax you show above seems reasonable, except that I am not sure
 about requiring
 that everything be put inside parentheses. That seems a bit confining
 for more complex
 conditions.


This is existing, working python syntax (although the decorators would
need to be defined).

 --
 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

Bruno Desthuilliers wrote:
 Russ a écrit :
  On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
  wrote:
 
 
 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.
 
 
  I get the strong impression you don't really understand what
  programming by contract is.

 I get the strong impression you don't really understand how
 condescending you are.

When someone writes something as ignorant as that, they need to be
called on it.

So you can implement everything you need already in Python? Yes, of
course, and you
can do it in machine language too -- if you have the time to waste.

  I have not yet personally used it,

 You have no working experience with the concept, but you think it should
 make it into Python's core ???

I don't need to use it to understand the concept. That has been
explained
brilliantly by the Eiffel and SPARK Ada folks.

I am also smart enough to figure out that
it can greatly enhance unit testing, and it can also be used as an
integral part of unit testing.
Once you have the conditions in place, all you need to do in your unit
tests is to send inputs
to the unit and wait to see if exceptions are thrown.

In fact, I would even propose a new name for programming by
contract. I would call it
self-testing code because the code essentially tests itself every
time it is run with the
checks activated.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Bruno Desthuilliers
Russ a écrit :
 Bruno Desthuilliers wrote:
 
Russ a écrit :
(snip)


I don't see how you can avoid adding some new syntax, given that
Python does not
currently have syntax for specifying invariants and pre- and post-
conditions.

class Parrot(object):
   @pre(lambda x : x != 42)
   @post(lambda result: result != 42)
   @invariant(lambda self: self.x == 42)
   def reliable_method(self, x):
 # your code here
 return something
 
 
 That looks like new syntax to me. 

It's the syntax for decorator functions, and it's not that new - it 
cames with Python 2.4, released November 30, 2004.

 Did I miss your point?

Yes.
-- 
http://mail.python.org/mailman/listinfo/python-list


RE: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Ryan Ginstrom
 On Behalf Of Russ
 Once you have the conditions in place, all you need to do in 
 your unit tests is to send inputs to the unit and wait to see 
 if exceptions are thrown.

That sounds a little ambitious to me...

However, you may want to look at the typecheck module (you can get it via
easy_install). I think you could probably extend it to do DBC.
http://oakwinter.com/code/typecheck/

 from typecheck import accepts, returns, Any
 @accepts(str, int, Any())
@returns(list)
def makelist(a, b, c):
return [a, b, c]

 makelist(spam, 42, object())
['spam', 42, object object at 0x00AE0470]
 makelist(42, spam, 3.4)

Traceback (most recent call last):
  File pyshell#25, line 1, in module
makelist(42, spam, 3.4)
  File
C:\Python25\lib\site-packages\typecheck-0.3.5-py2.5.egg\typecheck\__init__.
py, line 1340, in fake_function
  File
C:\Python25\lib\site-packages\typecheck-0.3.5-py2.5.egg\typecheck\__init__.
py, line 1419, in __check_args
TypeCheckError: Argument a: for 42, expected type 'str', got type 'int'
 

I tried using DBC for a time in C++ (using a library with a clever
assembly-language hack). I personally found it neater having such code in
unit tests, but obviously, it's a matter of preference.

Regards,
Ryan Ginstrom

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

  That looks like new syntax to me.

 It's the syntax for decorator functions, and it's not that new - it
 cames with Python 2.4, released November 30, 2004.

After looking more carefully at your example, I don't think it is as
clean and logical as the
PEP 316 syntax. At first I thought that your pre and post-conditions
applied to the class,
but now I realize that they apply to the function. I prefer to see the
conditions inside
the function in the doc string. That just seems more logical to me.
With all due respect,
your proposal is interesting, but I think it overextends the function
decorator idea a bit.

A nit-pick I might have with the PEP 316 syntax is that I think
invariant should be spelled
out rather than abbreviated as inv.  The same might apply to pre-
condition and
post-condition. But that's obviously no big deal.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Bruno Desthuilliers
Russ a écrit :
 Bruno Desthuilliers wrote:
 
Russ a écrit :

On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:



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.


I get the strong impression you don't really understand what
programming by contract is.

I get the strong impression you don't really understand how
condescending you are.
 
 
 When someone writes something as ignorant as that, they need to be
 called on it.

When someone writes something as arrogant as that, they need to be 
called on it.

Michele obviously knows what DbC is (probably better than you do), and 
he also knows Python enough to know why you don't need to add anything 
to Python to have it.

 So you can implement everything you need already in Python? 

Talking about DbC ?

 Yes, of
 course, 

Yes, of course. A couple of decorator functions and you're done. It's 
pretty trivial, and that's why Michele told you could implement it by 
yourself.

(snip)

I have not yet personally used it,

You have no working experience with the concept, but you think it should
make it into Python's core ???
  
 I don't need to use it to understand the concept. That has been
 explained
 brilliantly by the Eiffel and SPARK Ada folks.

FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why 
one can not hope to write reliable programs without strict static 
declarative type-checking.

One needs to have working experience with a concept to know what it's 
really worth. Too bad for you, you're too smart to understand this.

 I am also smart enough 

Yes, obviously really smart.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Bruno Desthuilliers
Russ a écrit :
That looks like new syntax to me.

It's the syntax for decorator functions, and it's not that new - it
cames with Python 2.4, released November 30, 2004.
 
 
 After looking more carefully at your example, I don't think it is as
 clean and logical as the
 PEP 316 syntax. 

Possibly not, but at least it's trivial to implement.

 At first I thought that your pre and post-conditions
 applied to the class,

Pre and post conditions applying to the class ? Now that's an 
interesting concept. IIRC, Eiffels pre and post conditions only apply to 
methods, and I fail to see how they could apply to a class. But since 
you're an expert on the subject, I don't doubt you'll enlighten us ?

 but now I realize that they apply to the function. I prefer to see the
 conditions inside
 the function in the doc string.  That just seems more logical to me.

Not to me. Doc strings are not for implementation. But if you want to 
implement a DbC module using doc strings, please do so.

 With all due respect,
 your proposal is interesting, but I think it overextends the function
 decorator idea a bit.

Definitively not, on the contrary - that's *exactly* what decorators are 
for. Else, they would be nothing more than HOFs, and there would be no 
point in having this syntactic sugar.

(snip).
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

Ryan Ginstrom wrote:

 I tried using DBC for a time in C++ (using a library with a clever
 assembly-language hack). I personally found it neater having such code in
 unit tests, but obviously, it's a matter of preference.

I agree that it ultimately boils down to preference, but as I tried to
explain earlier, I don't
think that unit tests are equivalent to DBC (or, as I referred to it
earlier, self-testing code).

Unit tests are not automatically executed when you run your
application. You need to write
the drivers and generate sample inputs to all the functions in your
application, which
can be very time-consuming. And if you think you can anticipate all
the weird internal data
that might come up in the execution of your application, then either
your application is very
simple or you are fooling yourself.

With self-testing code, on the other hand, all you need to do is to
get sample inputs to
your application (not internal inputs to functions) and run the entire
application. That is
much simpler and more comprehensive than unit testing.

Again, I recognize that it doesn't necessarily replace unit testing
completely. For one thing,
unit testing can test for specific outputs for specific inputs,
whereas you wouldn't want to
clutter your actual code with such specific cases. For example, a unit
test for a sorting
function could provide a specific input and test for a specific
output, but you probably
wouldn't want to clutter your code with such a case. The self-tests in
your code would be
more for general tests. PEP 316 provides an excellent of comprehensive
tests for a sorting
function. If you pass those tests, you can be sure your function
worked correctly.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 Pre and post conditions applying to the class ? Now that's an
 interesting concept. IIRC, Eiffels pre and post conditions only apply to
 methods, and I fail to see how they could apply to a class. But since
 you're an expert on the subject, I don't doubt you'll enlighten us ?

I made a simple mistake. Excuse me. Oh wait ... aren't you one of the
sensitivity police who
laid into me for criticizing someone else. For the record, the guy I
criticized
made ridiculous assertions about DBC. All I did was to make a simple
mistake about
an inconsequential matter. No, pre and post conditions obviously don't
apply to classes,
but all I said was that that's how it appeared to me at first
glance.

If you are upset about my criticism of one of your colleagues, please
tell him to quite making
outrageous assertions about something he obviously knows little about.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why
 one can not hope to write reliable programs without strict static
 declarative type-checking.

And they are probably right.

I don't think you understand what they mean by reliable
programs. Any idea how much Python is used for flight control systems
in commercial
transport aircraft or jet fighters? How about ballistic missile launch
and guidance systems?
Any idea why?

For the record, I think that DBS could possibly make Python more
suitable for *some*
mission-critical or perhaps even safety-critical applications, but it
will never be able
to compete with SPARK Ada or even Ada at the highest level of that
domain.

The important question is this: why do I waste my time with bozos like
you?

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Paul Rubin
Bruno Desthuilliers [EMAIL PROTECTED] writes:
 FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
 why one can not hope to write reliable programs without strict
 static declarative type-checking.

I don't know about Eiffel but at least an important subset of SPARK
Ada's DBC stuff is done using static analysis tools (not actually
built into the compiler as it happens) to verify statically
(i.e. without actually running the code) that the code fulfills the
DBC conditions.  I don't see any way to do that with Python
decorators.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

Paul Rubin wrote:
 Bruno Desthuilliers [EMAIL PROTECTED] writes:
  FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
  why one can not hope to write reliable programs without strict
  static declarative type-checking.

 I don't know about Eiffel but at least an important subset of SPARK
 Ada's DBC stuff is done using static analysis tools (not actually
 built into the compiler as it happens) to verify statically
 (i.e. without actually running the code) that the code fulfills the
 DBC conditions.  I don't see any way to do that with Python
 decorators.

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. With all
due respect, most (not all, but most) Python programmers never get
near such programs
and have no idea about how stringent the requirements are. Nor do most
programmers
in general, for that matter. (It's not an insult)

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Alex Martelli
Russ [EMAIL PROTECTED] wrote:
   ...
 programs. Any idea how much Python is used for flight control systems
 in commercial
 transport aircraft or jet fighters?

Are there differences in reliability requirements between the parts of
such control systems that run on aircraft themselves, and those that run
in airports' control towers?  Because Python *IS* used in the latter
case, cfr http://www.python.org/about/success/frequentis/ ... if
on-plane control SW requires hard-real-time response, that might be a
more credible reason why Python would be inappropriate (any garbage
collected language is NOT a candidate for hard-real-time SW!) than your
implied aspersions against Python's reliability.

According to
http://uptime.pingdom.com/site/month_summary/site_name/www.google.com,
Google's current uptime is around 99.99%, with many months at 100% and a
few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW,
and in real-world conditions where power can go away, network cables can
accidentally get cut, etc.  I'm Uber Tech Lead for Production Systems at
Google -- i.e., the groups I uber-lead are responsible for some software
which (partly by automating things as much as possible) empowers our
wondrous Site Reliability Engineers and network specialists to achieve
that uptime in face of all the Bad Stuff the world can and does throw at
us.  Guess what programming language I'm a well-known expert of...?


 The important question is this: why do I waste my time with bozos like
 you?

Yeah, good question indeed, and I'm asking myself that -- somebody who
posts to this group in order to attack the reliability of the language
the group is about (and appears to be supremely ignorant about its use
in air-traffic control and for high-reliability mission-critical
applications such as Google's Production Systems software) might well
be considered not worth responding to.  OTOH, you _did_ irritate me
enough that I feel happier for venting in response;-)

Oh, FYI -- among the many tasks I undertook in my quarter-century long
career was leading and coordinating pilot projects in Eiffel for one
employer, many years ago.  The result of the pilot was that Eiffel and
its DbC features didn't really let us save any of the extensive testing
we performed for C++-coded components, and the overall reliability of
such extensively tested components was not different in a statistically
significant way whether they were coded in C++ or Eiffel; Eiffel did let
us catch a few bugs marginally earlier (but then, I'm now convinced
that, at that distant time, we used by far too few unit-tests for early
bug catching and relied too much on regression and acceptance tests),
but that definitely was _not_ enough to pay for itself.  DbC and
allegedly rigorous compile-time typechecking (regularly too weak due to
Eiffel's covariant vs countervariant approach, btw...), based on those
empirical results, appear to be way overhyped.

A small decorator library supporting DbC would probably be a nice
addition to Python, but it should first prove itself in the field by
being released and supported as an add-on and gaining wide acceptance:
arguments such as yours are definitely NOT going to change that.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Ricardo Aráoz
Russ wrote:
 Paul Rubin wrote:
 Bruno Desthuilliers [EMAIL PROTECTED] writes:
 FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
 why one can not hope to write reliable programs without strict
 static declarative type-checking.
 I don't know about Eiffel but at least an important subset of SPARK
 Ada's DBC stuff is done using static analysis tools (not actually
 built into the compiler as it happens) to verify statically
 (i.e. without actually running the code) that the code fulfills the
 DBC conditions.  I don't see any way to do that with Python
 decorators.
 
 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'?

 With all
 due respect, most (not all, but most) Python programmers never get
 near such programs
 and have no idea about how stringent the requirements are. Nor do most
 programmers
 in general, for that matter. (It's not an insult)
 

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Carl Banks
On Aug 30, 10:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
 Russ [EMAIL PROTECTED] wrote:

...

  programs. Any idea how much Python is used for flight control systems
  in commercial
  transport aircraft or jet fighters?

 Are there differences in reliability requirements between the parts of
 such control systems that run on aircraft themselves, and those that run
 in airports' control towers?

Yes.

  Because Python *IS* used in the latter
 case, cfr http://www.python.org/about/success/frequentis/ ... if
 on-plane control SW requires hard-real-time response,

Yes.

 that might be a
 more credible reason why Python would be inappropriate (any garbage
 collected language is NOT a candidate for hard-real-time SW!) than your
 implied aspersions against Python's reliability.

Not really relevant, since there is no (or very little) dynamic memory
allocation.

Python really isn't suitable for in-flight controls for various
reasons, and mission critical concerns is a minor one (systems with
less underlying complexity tend to have fewer failure modes).  But
mostly it's raw throughput: Python is just too slow.  Flight control
computers have to be powerful enough make a ton of mathematical
calculations in a matter of milliseconds, and under strict weight and
power constraints.  The cost of running 100 times slower than optimal
is just too high.

At my current project, we're struggling with throughput even though we
use highly optimized code.  Python would be completely out of the
question.

Now, control towers don't have these constraints, and system failure
is not nearly as critical, so Python is a better option there.


Carl Banks

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Carl Banks
On Aug 30, 9:41 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
 Bruno Desthuilliers [EMAIL PROTECTED] writes:
  FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
  why one can not hope to write reliable programs without strict
  static declarative type-checking.

 I don't know about Eiffel but at least an important subset of SPARK
 Ada's DBC stuff is done using static analysis tools (not actually
 built into the compiler as it happens) to verify statically
 (i.e. without actually running the code) that the code fulfills the
 DBC conditions.  I don't see any way to do that with Python
 decorators.

I don't see any way to do that in Python with built-in DBC syntax,
either.  :)


Carl Banks

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Robert Brown

[EMAIL PROTECTED] (Alex Martelli) writes:
 DbC and allegedly rigorous compile-time typechecking (regularly too weak
 due to Eiffel's covariant vs countervariant approach, btw...), based on
 those empirical results, appear to be way overhyped.

My experience with writing Eiffel code was a bit different.  Integrating
code from multiple sources happened much faster than I expected, and the
code ran reliably.  There were a couple of instances where previously
uncombined code was linked together and worked on the first run.

Perhaps more important, however, is that method contracts provide important
documentation about how each method is supposed to work -- what it assumes
and what must be true when it returns.  Using Eiffel changed my coding
process.  Often I'd write the pre- and postconditions first, then write the
method body, just as programmers today often write unit tests first.
Thinking carefully about the contracts and writing them down, so they could
be verified, makes the code more reliable and maintainable.  The contracts
are part of the source code, not a fuzzy concept in each programmer's head.

The contracts are also useful when discussing the code with domain experts
who are not programmers.  They can read and understand the flat short view
of a class, which includes all the method names, method comments, and
contracts, but leaves out the method implementations.  Here's an example,
Eiffel's String class: http://www.nenie.org/eiffel/flatshort/string.html

In any case, I'm still not sure whether it would be useful to integrate DbC
into Python.  A library that implements DbC for Common Lisp has not gotten
much traction in that community, which has a similar style of software
development.  Perhaps it's just too much to ask that programmers write both
unit tests and method contracts.

bob
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Paul Rubin
Robert Brown [EMAIL PROTECTED] writes:
 In any case, I'm still not sure whether it would be useful to integrate DbC
 into Python.  

I guess I'm a little confused about what it would mean.  Suppose you
want to write a function that looks for a value using binary search
in a sorted list, n = bsearch(a,x).  The contract is:

  precondition: the input list a is sorted.
  postcondition: the output is an integer n, such that if
 x is an element of the list, then a[n] == x.  If x is not
 in the list, then n is -1.

This is a reasonable application of dbc since the precondition and
postcondition are easy to specify and check, but the binary search
algorithm is tricky enough to be susceptible to implementation errors.

The trouble is, the obvious way to write the precondition and
postcondition take linear time, while the binary search should take
log(n) time.  In the traditional unit test approach, that's ok, you'd
run the test as part of the build process but not each time the
function is actually called.  With something like SPARK/Ada (and maybe
Eiffel), you'd statically validate the conditions.  But in Python, the
check occurs at runtime unless you disable it, famously compared to
wearing your parachute on the ground but taking it off once your plane
is in the air.

I guess one difference from unit test philosophy is that at least
sometime, you'd run the entire application with all the dbc checks
enabled, and just live with the slowdown.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Roy Smith
Carl Banks [EMAIL PROTECTED] wrote:
 Python really isn't suitable for in-flight controls for various
 reasons, and mission critical concerns is a minor one (systems with
 less underlying complexity tend to have fewer failure modes).  But
 mostly it's raw throughput: Python is just too slow.  Flight control
 computers have to be powerful enough make a ton of mathematical
 calculations in a matter of milliseconds, and under strict weight and
 power constraints.  The cost of running 100 times slower than optimal
 is just too high.

I'm not convinced that's true for all avionics uses.  Certainly, if you're 
doing the fly-by-wire stability control system for a dynamically unstable 
airframe, you need a lot of compute power and guaranteed real-time response 
(recovery from a VMC rollover is no time for garbage collection).  But, not 
everything in an airplane is like that.

Take something relatively complicated like a GPS.  The basic receiver is 
pretty compute intensive, but that's likely to be a dedicated chip.  Most 
of the functionality in the box, however, requires a lot less horsepower.  
You need to handle user input (i.e. keep up a scan on maybe 20 keys), and 
update a low-res display (320 x 240 x 8 bit color is typical) with text or 
cartoon graphics.  There are certain real-time calculations which need to 
be done, such as time, distance, and bearing to the next waypoint, but 
these are typically updated a few times a second.

Like most things that use Python (or TCL, or Ruby, or ...), I would expect 
that most of the low-level stuff would be done in something like C and 
Python would be used for the glue code and things where there's no time 
pressure.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 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.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Michele Simionato
On Aug 31, 3:18 am, Russ [EMAIL PROTECTED] wrote:
 For the record, the guy I
 criticized
 made ridiculous assertions about DBC.

And that would be me? Oh my! LOL!
This is not nearly as fun as the guy who explained to Steve Holden how
Python works, but still ... ;)

 If you are upset about my criticism of one of your colleagues, please
 tell him to quite making
 outrageous assertions about something he obviously knows little about.

For the record I read the design by contract book by Meyer
years ago (the first edition) and I could not stomach it.
The paper you mentioned is even worse. Programmers asserting
that a given metodology can give 100% reliable software
are incompetents or liars or both. Period.

Of course there are methodologies which are better than
others (for instance automatic tests are better than
manual tests) and one should try various approaches on
the field.

However, IMNSHO, nowadays design by contract has been superseded
by unit tests and it makes little sense to use it. Once
you have automatic tests and once you make liberal use of
assert statements in your code, you should not feel the need
for more than that. You may think differently of course,
but you should know that I am a ferocious opponent of
heavyweight approaches, huge frameworks, and all that.
Most people in the Python community are. This is why I
think dBC will never enter in the core, and it would be
extremely little used even as a third party library
(BTW, it has already happened).

Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-30 Thread Russ

 I guess one difference from unit test philosophy is  that at least
 sometime, you'd run the entire application with all  the dbc checks
 enabled, and just live with the slowdown.

Yes, that's right. You don't expect to run efficiently with the self-
test checks activated, but you can test your code more conveniently
and comprehensively than unit tests by simply running your program as
usual -- except with the checks activated. If you do that for any
significant period of time, many bugs will find themselves, I'm sure.

Also, to repeat once again, the embedded self-test (DbC) checks can be
used for unit testing too. You simply activate the self-tests when you
do your unit testing, and wait for them to throw exceptions. So it
seems to me that you've killed two birds with one stone.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Michele Simionato
On Aug 29, 7:21 am, Russ [EMAIL PROTECTED] wrote:

 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?

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.

 In any case, I guess it is still perfectly usable even if it isn't
 part of the core Python. Has anyone used it? If so, how well did it
 work? Thanks.

Dunno, I would be curious myself to know if there are users
of these frameworks (including AOP frameworks in Python) or
if they are just exercises.

   Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Russ
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:

 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.

I get the strong impression you don't really understand what
programming by contract is.

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
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:

http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Michele Simionato
On Aug 29, 8:45 am, Russ [EMAIL PROTECTED] wrote:
 I get the strong impression you don't really understand what
 programming by contract is.

 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
 to be correct and reliable as possible, I think you you should be
 interested in it. You might want to read this:

 http://archive.eiffel.com/doc/manuals/technology/contract/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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Aahz
In article [EMAIL PROTECTED],
Russ  [EMAIL PROTECTED] wrote:

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.python,
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.

The way to get this into Python is to get people to use it as a
stand-alone module.  It's already in PyPI, so now it's time for some
marketing.
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

If you don't know what your program is supposed to do, you'd better not
start writing it.  --Dijkstra
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Chris Mellon
On 8/29/07, Russ [EMAIL PROTECTED] wrote:
 On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
 wrote:

  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.

 I get the strong impression you don't really understand what
 programming by contract is.


Don't be condescending.

 I have not yet personally used it, but I am interested in anything
 that can help to make my programs more reliable.

The entire issue of software reliability, exactly what metrics you
should use to measure it, and whether any specific technique results
in more of it are very much in debate. If you want to experiment with
these techniques, you can do so without them being in the Python core.
Python has all the support you need to play with them right now.

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
 to be correct and reliable as possible, I think you you should be
 interested in it. You might want to read this:


You don't want your software to KILL BABIES, do you? If you don't want
your programs to KILL BABIES then you should use our technique, so you
don't KILL BABIES.

There are ways to make correct programs besides DBC. It may not even
help in the general case - just as with unit testing and type proving,
you're going to be limited by what you don't think to assert or
document or test, and I've seen no evidence that DBC is any better
than anything else at preventing unwritten assumptions.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Steve Holden
Chris Mellon wrote:
 On 8/29/07, Russ [EMAIL PROTECTED] wrote:
[...]
 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
 to be correct and reliable as possible, I think you you should be
 interested in it. You might want to read this:

 
 You don't want your software to KILL BABIES, do you? If you don't want
 your programs to KILL BABIES then you should use our technique, so you
 don't KILL BABIES.
 
 There are ways to make correct programs besides DBC. It may not even
 help in the general case - just as with unit testing and type proving,
 you're going to be limited by what you don't think to assert or
 document or test, and I've seen no evidence that DBC is any better
 than anything else at preventing unwritten assumptions.

Personally I have found the best strategy to be KWYD: know what you're 
doing. Your assertion that success of DBC relies on the competence of 
the practitioner is indeed true, just as it is for all other 
methodologies. The number of programmers who *don't* know what they are 
doing and yet manage to find well-paid employment in mission-critical 
system implementation is truly staggering.

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. Nevertheless I 
would hesitate to write code for such demanding areas as real-time 
rocket flight control, because I just don't think I'm that good. Very 
few people are, and learning as you go can be disastrously expensive 
when military and space projects are involved.

But it's always a good idea to make your software correct and as 
reliable as possible, isn't it? The problem is the external constraints 
on the project. As the old saying goes: Cheap, fast, reliable: choose 
any two.

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 -

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Dan Stromberg - Datallegro
On Tue, 28 Aug 2007 23:45:28 -0700, Russ wrote:

 On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
 wrote:
 
 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.
 
 I get the strong impression you don't really understand what
 programming by contract is.
 
 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
 to be correct and reliable as possible, I think you you should be
 interested in it. You might want to read this:
 
 http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

I agree with Chris - there's no need to be condescending.

However, I agree with you that this is a valuable addition to a language.

It's not that Eiffel, by having preconditions and postconditions, is doing
anything that cannot be done in python already.

It's more that by making these things a formal part of the language, or at
least a module that facilitates them, one gives a sort of stamp of
approval to adding a ton of assertions about how your code is supposed to
work /when/working/in/that/language, which makes debugging a relative
snap.  Isn't that something people should want for python?  Sturdy code
and easy debugging?

I've been trying to write my python code with tons of unnecessary if
statements that check out my assumptions, and I'm finding more or less
what the Eiffel people claim: I'm investing a little bit of upfront time,
and getting a huge payoff in the backend as my code starts to debug
itself.  But I likely never would've started taking my error checking to
such extremes if I hadn't been curious about Eiffel for a while.

Throwing in tons of error and assumption checking mostly eliminates silly
tracing from procedure to function to procedure to function, trying to
find the ultimate root cause of a problem.  Usually, the root cause is
identified in an error on stderr or similar.

Keep in mind that debugging usually takes far longer than the initial
coding.  Programming by contract seems to balance that out, relatively
speaking.

Granted, we could just say You should check for these things anyway, or
You should know what you're doing, but...  Isn't that kind of what
assembler programmers used to say to Lisp, FORTRAN and COBOL programmers? 

And what about the case where you've written a piece of code, and
someone else has written another, and the two pieces of code need to
interact?  Odds are pretty good that if this code has much substance,
there'll be opportunity for subtly different assumptions about what should
be happening in each (yes, well abstracted code will be
misassumption-resistant, but even the best OOP programmers will run afoul
of this /sometimes/). Perhaps both these programmers Know what they're
doing, but they don't necessarily know what the other is doing!

IMO, putting Programming by Contract into python as part of the language
itself, or as a simple module, is a little bit like a company or
department coming up with a mission statement.  It's easy to say that it's
meaningless, and some will ignore it, but it still kind of sets the tone
for how things should be done.


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Russ

 But it's always a good idea to make your software correct and as
 reliable as possible, isn't it? The problem is the external constraints
 on the project. As the old saying goes: Cheap, fast, reliable: choose
 any two.

If you are suggesting that programming by contract is not
appropriate for every application, you will get no argument from me.
All I am suggesting is that having the option to use it when you need
it is very desirable, and it can possibly enhance the versatility of
Python by making Python more suitable for *some* mission-critical
applications.

I once read a book on something called SPARK Ada, which also supports
programming by contract. I was pleasantly surprised to discover
yesterday that support for the such methods is also available for
Python. However, the support would obviously be a bit stronger if it
were in the core Python distribution.

What I really like about the implementation I cited above is that the
invariants and the pre and post-conditions can all be put right in the
doc string at the beginning of each class or function. You can think
of it as a detailed specification of the intent (or of some of the
requirements or constraints) of the class or function -- which can be
*automatically* checked during testing. It can also be used for
explicit type checking.

It's like having some of your most critical unit tests built right
into your code. It may make your code very verbose, but it will also
be very complete.



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-29 Thread Michele Simionato
On Aug 30, 1:17 am, Dan Stromberg - Datallegro
[EMAIL PROTECTED] wrote:
 IMO, putting Programming by Contract into python as part of the language
 itself, or as a simple module, is a little bit like a company or
 department coming up with a mission statement.  It's easy to say that it's
 meaningless, and some will ignore it, but it still kind of sets the tone
 for how things should be done.

I disagree. IMO automatic testing is thousands of times better than
design by contract and Python has already all the support you need
(unittest, doctest, py.test, nose, ...)


 Michele Simionato

-- 
http://mail.python.org/mailman/listinfo/python-list


status of Programming by Contract (PEP 316)?

2007-08-28 Thread Russ
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.python,
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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-28 Thread Steven Bethard
Russ wrote:
 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.python,
 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.

PEP's with deferred status typically aren't going into Python any time 
soon, if ever.  Since the due date for all Python 3 core changes is long 
past due, you won't even be seeing it in Python 3.

Steve
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: status of Programming by Contract (PEP 316)?

2007-08-28 Thread Russ
On Aug 28, 9:35 pm, Steven Bethard [EMAIL PROTECTED] wrote:
 Russ wrote:
  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.python,
  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.

 PEP's with deferred status typically aren't going into Python any time
 soon, if ever.  Since the due date for all Python 3 core changes is long
 past due, you won't even be seeing it in Python 3.

 Steve

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?

In any case, I guess it is still perfectly usable even if it isn't
part of the core Python. Has anyone used it? If so, how well did it
work? Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list