status of Programming by Contract (PEP 316)?
Russ
(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.
Steven Bethard
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
Russ
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.
Michele Simionato
>
> 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
Russ
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
Michele Simionato
> 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:
>
That paper contains only a good think: a link to the contrarian view
http://home.flash.net/~kennieg/ariane.html#s3.1.5
Aahz
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 (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Chris Mellon
> On Aug 28, 10:58 pm, Michele Simionato <michele.simion...@gmail.com>
> 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.
Steve Holden
>> 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:
>>
>
> 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 -------------
Dan Stromberg - Datallegro
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".
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.
Michele Simionato
<dstromb...@datallegro.com> 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
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.
Chris Mellon
> > 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.
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.
Chris Mellon
>
> > 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.
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.
Bruno Desthuilliers
(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
Bruno Desthuilliers
> On Aug 28, 10:58 pm, Michele Simionato <michele.simion...@gmail.com>
> 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 ???
Russ
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.
Chris Mellon
This is existing, working python syntax (although the decorators would
need to be defined).
Russ
Bruno Desthuilliers wrote:
> Russ a écrit :
> > On Aug 28, 10:58 pm, Michele Simionato <michele.simion...@gmail.com>
> > 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.
Bruno Desthuilliers
> 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.
Ryan Ginstrom
> 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
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.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>Russ a écrit :
>>
>>>On Aug 28, 10:58 pm, Michele Simionato <michele.simion...@gmail.com>
>>>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.
Bruno Desthuilliers
>>>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).
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.
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.
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?
Paul Rubin
> 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.
Russ
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)
Alex Martelli
...
> 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
Ricardo Aráoz
> Paul Rubin wrote:
>> Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> 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'?
Carl Banks
> Russ <uymqlp...@sneakemail.com> 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
Carl Banks
I don't see any way to do that in Python with built-in DBC syntax,
either. :)
Carl Banks
Robert Brown
al...@mac.com (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
Paul Rubin
> 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.
Roy Smith
> 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.
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.
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
> Carl Banks <pavlove...@gmail.com> 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
Russ
> Russ <uymqlp...@sneakemail.com> 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 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.
Carl Banks
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
Bruno Desthuilliers
>> 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...
Bruno Desthuilliers
>> 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.
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:
> On Aug 29, 7:21 am, Russ <uymqlp...@sneakemail.com> 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
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
> > 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.
Ricardo Aráoz
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.:
Neil Cerutti
> 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
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
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
Steve Holden
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
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.
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.
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.
Steve Holden
> 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.
>
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.
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.
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.
Ricardo Aráoz
> On 2007-08-31, Ricardo Aráoz <rica...@gmail.com> 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.
Jorge Godoy
> 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.
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.
Steve Holden
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.
Carl Banks
On the systems I work on, the OS is unit tested same as the application
software. Not sure about the compiler; I'm pretty sure we're not using
the latest GCC beta, though.
Carl Banks
Russ
> 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.
Carl Banks
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.)
Paul Rubin
> 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.
Hendrik van Rooyen
> 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
Marc 'BlackJack' Rintsch
> "Carl Banks" <pavl....mail.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
llothar
> 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.
Bryan Olson
[...]
> 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
Jorge Godoy
> 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.
Steve Holden
> 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.
>
aren't experienced in smaller scale projects such as the ones I mentioned.
> I work on large and complex systems. If I screw up -- O.K., face
> facts: *when* I screw up -- the chance of the issue being assigned
> to me is small. Other engineers will own the problems I cause,
> while I work on defects in code I've never touched. I wish I could
> own all my own bugs, but that's not how large and complex systems
> work. Root-cause analysis is the hard part. By the time we know
> what went wrong, 99.99% of the work is done.
>
This is the kind of realism I like to see in engineering. I am always
suspicious when any method is promoted as capable of reducing the error
rate to zero.
>
> Design-by-contract (or programming-by-contract) shines in large
> and complex projects, though it is not a radical new idea in
> software engineering. We pretty much generally agree that we want
> strong interfaces to encapsulate implementation complexity.
> That's what design-by-contract is really about.
>
> There is no strong case for adding new features to Python
> specifically for design-by-contract. The language is flexible
> enough to support optionally-executed pre-condition and
> post-condition checks, without any extension. The good and bad
> features of Python for realizing reliable abstraction are set
> and unlikely to change. Python's consistency and flexibility
> are laudable, while duck-typing is a convenience that will
> always make it less reliable than more type-strict languages.
>
Python's dynamic nature certainly makes it more difficult to reason
about programs in any formal sense. I've always thought of it as a
pragmatist's language, and we need to be pragmatic about the downside as
well as the upside.
Steve Holden
> 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.
>
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.
>
Ricardo Aráoz
>> 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.
>
> critical?
>
> Most dams just hold water back.
>
> 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)
Pierre Hanser
>
> 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.
Terry Reedy
"Hendrik van Rooyen" <ma...@microcorp.co.za> wrote in message
news:026201c7ec75$07d6e0c0$03000080@hendrik...
| This really intrigues me - how do you program a dam? - and why is it
| critical?
|
| Most dams just hold water back.
Most big dams also generate electricity. Even without that, dams do not
just hold water back, they regulate the flow over a year or longer cycle.
A full dam is great for power generation and useless for flood control. An
empty dam is great for flood control and useless for power generation. So
both power generation and bypass release must be regulated in light of
current level, anticipated upstream precipitation, and downstream
obligations. Downstream obligations can include both a minimum flow rate
for downstream users and a maximum rate so as to not flood downstream
areas.
tjr
Alex Martelli
...
> 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.10400000000000004
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
Alex Martelli
...
> > > 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
Ricardo Aráoz
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.
Carl Banks
> 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
Carl Banks
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
Alex Martelli
...
> >> 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 glib and false assertions: I *DO* care that these falsities, these
extremely serious errors that stand in the way of proper system
thinking, be never left unchallenged and uncorrected. Unfortunately a
*LOT* of people (including, shudder, ones who are responsible for
architecting, designing and implementing some systems) are under very
serious misapprehensions that impede "system thinking", some of the same
ilk as your falsities (looking at only PART of the system and never the
whole, using far-too-simplified rules of thumbs to estimate system
properties, and so forth), some nearly reversed (missing opportunities
to make systems *simpler*, overly focusing on separate components, &c).
As to your specific point about "program proofs" being likely overkill
(which doesn't mean "useless", but rather means "low ROI" compared to
spending comparable resources in other reliability enhancements), that's
probably true in many cases. But when a probably-true thesis is being
"defended" by tainted means, such as false assertions and excessive
simplifications that may cause serious damage if generally accepted and
applied to other issues, debunking the falsities in question is and
remains priority number 1 for me.
Alex
Russ
> 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.
Russ
> 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 R&D 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.
Michele Simionato
> 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
Russ
> 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.
Paul Rubin
> > 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 R&D 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.
Russ
> 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.
Russ
> 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
Ricardo Aráoz
> Ricardo Aráoz <rica...@gmail.com> 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.
Aahz
Russ <uymq...@sneakemail.com> 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 (aa...@pythoncraft.com) <*> 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
Bruno Desthuilliers
(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)