status of Programming by Contract (PEP 316)?

[Michele Simionato]

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

 

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

 

[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"?

 

[Carl Banks]

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

 

[Carl Banks]

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

 

[Russ]

...

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.

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 implementation is very unlikely to be in Python.
Even so, I would like to make my prototype as reliable
as possible, and that is why I am interested in the
idea of self-testing code or "programming by contract."

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.

First of all, I am having a hard time reading your post
because Google is forcing me to scroll horizontally to
read each line. But all I can say is that your experience
with self-testing code doesn't seem to be consistent
with the experience of many others who have used it. Is it
possible that you didn't use it to its fullest extent?

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.

I'm sorry to see that you are so closed-minded about the
idea. I get the impression that you are close to the
Benevelent Dictator, but I can only hope that he remains
more open minded than you. I already explained why I don't like
the "decorator" approach (it puts the conditions outside
of the body of the function, for one thing).

I can only say that I am happy that I can always use
the implementation described in PEP 316. That's the
beauty of open source, isn't it.

 

[Bruno Desthuilliers]

Russ a écrit :

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

 

[Bruno Desthuilliers]

Russ a écrit :

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.

 

[Michele Simionato]

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:

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

 

[Paul Rubin]

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.

 

[Paul Rubin]

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.

 

[=?ISO-8859-1?Q?Ricardo_Ar=E1oz?=]

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

Same as above, if I am not mistaken.


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.

 

[Paul Rubin]

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

 

[Neil Cerutti]

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?

 

[Alex Martelli]

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 deployed selectively, and the whole panoply may
chosen to be arrayed only for what an organization considers to be its
truly mission critical applications -- Google's "pillars" used to be
search and ads, but has more recently been officially declared to now be
"Search, Ads and Apps" (cfr
<http://searchengineland.com/070511-092730.php> and links therefrom for
some discussion about this), which may have implications... but Python
remains at the core of many aspects of our reliability strategy.


Alex

 

[Alex Martelli]

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

 

[Steve Holden]

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

Same as above, if I am not mistaken.


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

 

[Russ]

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.

 

[Russ]

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.

 

[Russ]

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.