Russ a écrit :
(snip)
Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior
here, where
outsiders like me are held to a higher standard than your insider
friends. I don't know who you are, nor do I care what you and your
little group think about me.
If you took time to
Russ [EMAIL PROTECTED] writes:
try:
blah blah with as many return statements as you want
finally:
something that gets executed unconditionally at the end
Thanks. I didn't think of that.
So design by contract *is* relatively easy to use in Python already.
The main issue, I suppose,
On Sep 1, 10:05 pm, Russ [EMAIL PROTECTED] wrote:
changing the language itself. Someone please correct me if I am wrong,
but I think PEP adds only to the libraries.
I meant to write PEP 316, of course.
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 1, 11:04 pm, Paul Rubin wrote:
I still don't understand why you don't like the decorator approach,
which can easily implement the above.
Well, maybe decorators are the answer. If a function needs only one
decorator for all the conditions and invariants (pre and post-
conditions), and if
Alex Martelli wrote:
Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component,
...
You win the argument, and thanks you prove my point. You typically
concerned yourself with
In article [EMAIL PROTECTED],
Russ [EMAIL PROTECTED] wrote:
Excellent points. As for no strong case for adding new features to
Python specifically for design-by-contract, if you mean adding
something to language itself, I agree, but I see nothing wrong with
adding it to the standard libraries,
On Fri, 31 Aug 2007 22:18:09 -0300, Jorge Godoy wrote:
Russ wrote:
Alex, I think you are missing the point. Yes, I'm sure that web
searches are critical to
Google's mission and commercial success. But the point is that a few
subtle bugs cannot
destroy Google. If your search engines and
Russ [EMAIL PROTECTED] writes:
The idea here is that errors in the self-testing code are unlikely
to be correlated with errors in the primary code. Hence, you get a
sort of multiplying effect on reliability. For example, if the
chance of error in the primary code and the self-test code are
Carl Banks pavlmail.com wrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the
On Sat, 01 Sep 2007 10:34:08 +0200, Hendrik van Rooyen wrote:
Carl Banks pavlmail.com wrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your
On 29 Aug., 13:45, Russ [EMAIL PROTECTED] wrote:
I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need
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
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
Bryan Olson wrote:
Steve Holden wrote:
[...]
If I can blow my own trumpet briefly, two customers (each using over 25
kLOC I have delivered over the years) ran for two years while I was away
in the UK without having to make a single support call. One of the
systems was actually locked in a
Hendrik van Rooyen wrote:
Carl Banks pavlmail.com wrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really
Carl Banks a écrit :
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in your
flagship product is a critical problem *for your company*, but are you
really trying to say that the criticalness of a bad
Hendrik van Rooyen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| This really intrigues me - how do you program a dam? - and why is it
| critical?
|
| Most dams just hold water back.
Most big dams also generate electricity. Even without that, dams do not
just hold water back,
Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component,
Not true (not even for security, much less for reliability which is
what's being discussed here).
It's easy to see how this
Russ [EMAIL PROTECTED] wrote:
...
the inputs. To test the
post-conditions, you just need a call at the bottom of the function,
just before the return,
...
there's nothing to stop you putting the calls before every return.
Oops! I didn't think of that. The idea of putting one
Alex Martelli wrote:
Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component,
Not true (not even for security, much less for reliability which is
what's being discussed here).
On Sat, 01 Sep 2007 08:38:38 -0300, Jorge Godoy wrote:
Carl Banks wrote:
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in
your flagship product is a critical problem *for your company*, but are
you
On Sat, 01 Sep 2007 17:19:49 +0200, Pierre Hanser wrote:
Carl Banks a écrit :
This is starting to sound silly, people. Critical is a relative term,
and one project's critical may be anothers mundane. Sure a flaw in
your flagship product is a critical problem *for your company*, but are
Ricardo Aráoz [EMAIL PROTECTED] wrote:
...
We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component,
...
You win the argument, and thanks you prove my point. You typically
concerned yourself with the technical part of
On Sep 1, 4:25 am, Bryan Olson
Design-by-contract (or programming-by-contract) shines in large
and complex projects, though it is not a radical new idea in
software engineering. We pretty much generally agree that we want
strong interfaces to encapsulate implementation complexity.
That's
On Sep 1, 6:51 pm, [EMAIL PROTECTED] (Alex Martelli)
try:
blah blah with as many return statements as you want
finally:
something that gets executed unconditionally at the end
Thanks. I didn't think of that.
So design by contract *is* relatively easy to use in Python already.
The main
On Sep 2, 7:05 am, Russ [EMAIL PROTECTED] wrote:
Someone please correct me if I am wrong,
but I think PEP adds only to the libraries.
You are wrong, PEPs also add to the core language. Why don't you give
a look
at the PEP parade on python.org?
Michele Simionato
--
On Sep 1, 10:44 pm, Russ [EMAIL PROTECTED] wrote:
On, one more thing. I see that the line wrapping on Google Groups is
finally working for me after many months. Fantastic! I can't help but
wonder if my mentioning it to you a few days ago had anything to do
with it.
Well, it's working on the
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
On Fri, 31 Aug 2007 01:15:04 -0400, Roy Smith wrote:
Carl Banks [EMAIL PROTECTED] wrote:
Python really isn't suitable for in-flight controls for various
reasons, and mission critical concerns is a minor one (systems with
less underlying complexity tend to have fewer failure modes). But
On Aug 30, 7:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
Russ [EMAIL PROTECTED] wrote:
...
programs. Any idea how much Python is used for flight control systems
in commercial
transport aircraft or jet fighters?
Hi Alex. I've always enjoyed your Piggies talks at
Google (although
On Thu, 30 Aug 2007 22:56:54 -0700, Russ wrote:
Python really isn't suitable for in-flight controls for various
reasons, and mission critical concerns is a minor one (systems with
Do you know anything about the FAA certification process for flight-
critical systems? I am not an expert on
Russ a écrit :
Pre and post conditions applying to the class ? Now that's an
interesting concept. IIRC, Eiffels pre and post conditions only apply to
methods, and I fail to see how they could apply to a class. But since
you're an expert on the subject, I don't doubt you'll enlighten us ?
I
Russ a écrit :
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why
one can not hope to write reliable programs without strict static
declarative type-checking.
And they are probably right.
And they are obviously wrong, by empiric experience.
I don't think you understand
On Aug 31, 10:02 am, Russ [EMAIL PROTECTED] wrote:
Hi Alex. I've always enjoyed your Piggies talks at
Google (although I missed he last one because I was out
of town). I'm disappointed to see that you seem to have
taken personal offense from remarks I made to someone else who
attacked me
[EMAIL PROTECTED] (Alex Martelli) writes:
Yeah, good question indeed, and I'm asking myself that -- somebody who
posts to this group in order to attack the reliability of the language
the group is about (and appears to be supremely ignorant about its use
in air-traffic control and for
Michele Simionato [EMAIL PROTECTED] writes:
http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page...
That paper contains only a good think: a link to the contrarian view
http://home.flash.net/~kennieg/ariane.html#s3.1.5
I like the contrarian article much better than the
Russ wrote:
I've always wondered... Are the compilers (or interpreters), which take
these programs to machine code, also formally proven correct?
No, they are not formally proven correct (too complicated for that),
but I believe they are certified to a higher level than your typical
Ricardo Aráoz [EMAIL PROTECTED] writes:
In that case why don't we just 'certify to a higher level' the programs
and get done with this formal proofs? We should remember that the level
of security of a 'System' is the same as the level of security of it's
weakest component, so either we
On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote:
Russ wrote:
Yes, thanks for reminding me about that. With SPARK Ada, it is
possible for some real (non-trivial) applications to formally
(i.e., mathematically) *prove* correctness by static analysis.
I doubt that is possible without static
Paul Rubin http://[EMAIL PROTECTED] wrote:
...
Hi Alex, I'm a little confused: does Production Systems mean stuff
like the Google search engine, which (as you described further up in
your message) achieves its reliability at least partly by massive
redundancy and failover when something
Michele Simionato [EMAIL PROTECTED] wrote:
...
I would not call that an attack. If you want to see an attack, wait
for
Alex replying to you observations about the low quality of code at
Google! ;)
I'm not going to deny that Google Groups has glitches, particularly in
its user interface
Russ wrote:
I've always wondered... Are the compilers (or interpreters), which take
these programs to machine code, also formally proven correct?
No, they are not formally proven correct (too complicated for that),
but I believe they are certified to a higher level than your typical
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
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.
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
Russ wrote:
Steve Holden wrote:
Frankly I am getting a little tired of they way you are unable to even
recognize that your readers may well have a sensible appreciation of the
difficulties about which you write. As has been pointed out already,
many readers here are extremely experienced
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
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
Neil Cerutti wrote:
On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote:
Russ wrote:
Yes, thanks for reminding me about that. With SPARK Ada, it is
possible for some real (non-trivial) applications to formally
(i.e., mathematically) *prove* correctness by static analysis.
I doubt that is
Russ wrote:
Alex, I think you are missing the point. Yes, I'm sure that web
searches are critical to
Google's mission and commercial success. But the point is that a few
subtle bugs cannot
destroy Google. If your search engines and associated systems have
bugs, you fix them
(or simply
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
Jorge Godoy wrote:
Russ wrote:
Alex, I think you are missing the point. Yes, I'm sure that web
searches are critical to
Google's mission and commercial success. But the point is that a few
subtle bugs cannot
destroy Google. If your search engines and associated systems have
bugs, you fix
On Aug 31, 6:45 pm, Steve Holden
We probably need to distinguish between mission-critical, where a
program has to work reliably for an organization to meet its goals, and
safety-critical where people die or get hurt if the program misbehaves.
The term mission critical itself can have a wide
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,
On 8/29/07, Russ [EMAIL PROTECTED] wrote:
But it's always a good idea to make your software correct and as
reliable as possible, isn't it? The problem is the external constraints
on the project. As the old saying goes: Cheap, fast, reliable: choose
any two.
If you are suggesting that
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
On 8/30/07, Russ [EMAIL PROTECTED] wrote:
PEP 316 introduces new syntax for a limited use feature. That's pretty
much a no-starter, in my opinion, and past experience tends to bear
that out. Furthermore, it predates decorators and context managers,
which give all the syntax support you
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.
--
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
Russ a écrit :
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python
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:
On 8/30/07, Russ [EMAIL PROTECTED] wrote:
Bruno Desthuilliers wrote:
Russ a écrit :
(snip)
I don't see how you can avoid adding some new syntax, given that
Python does not
currently have syntax for specifying invariants and pre- and post-
conditions.
class Parrot(object):
Bruno Desthuilliers wrote:
Russ a écrit :
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it
Russ a écrit :
Bruno Desthuilliers wrote:
Russ a écrit :
(snip)
I don't see how you can avoid adding some new syntax, given that
Python does not
currently have syntax for specifying invariants and pre- and post-
conditions.
class Parrot(object):
@pre(lambda x : x != 42)
@post(lambda
On Behalf Of Russ
Once you have the conditions in place, all you need to do in
your unit tests is to send inputs to the unit and wait to see
if exceptions are thrown.
That sounds a little ambitious to me...
However, you may want to look at the typecheck module (you can get it via
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
Russ a écrit :
Bruno Desthuilliers wrote:
Russ a écrit :
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining
Russ a écrit :
That looks like new syntax to me.
It's the syntax for decorator functions, and it's not that new - it
cames with Python 2.4, released November 30, 2004.
After looking more carefully at your example, I don't think it is as
clean and logical as the
PEP 316 syntax.
Possibly
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
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
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
Bruno Desthuilliers [EMAIL PROTECTED] writes:
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
why one can not hope to write reliable programs without strict
static declarative type-checking.
I don't know about Eiffel but at least an important subset of SPARK
Ada's DBC stuff is
Paul Rubin wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
why one can not hope to write reliable programs without strict
static declarative type-checking.
I don't know about Eiffel but at least an important subset of
Russ [EMAIL PROTECTED] wrote:
...
programs. Any idea how much Python is used for flight control systems
in commercial
transport aircraft or jet fighters?
Are there differences in reliability requirements between the parts of
such control systems that run on aircraft themselves, and those
Russ wrote:
Paul Rubin wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
why one can not hope to write reliable programs without strict
static declarative type-checking.
I don't know about Eiffel but at least an important
On Aug 30, 10:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
Russ [EMAIL PROTECTED] wrote:
...
programs. Any idea how much Python is used for flight control systems
in commercial
transport aircraft or jet fighters?
Are there differences in reliability requirements between the parts
On Aug 30, 9:41 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
Bruno Desthuilliers [EMAIL PROTECTED] writes:
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained
why one can not hope to write reliable programs without strict
static declarative type-checking.
I don't know about
[EMAIL PROTECTED] (Alex Martelli) writes:
DbC and allegedly rigorous compile-time typechecking (regularly too weak
due to Eiffel's covariant vs countervariant approach, btw...), based on
those empirical results, appear to be way overhyped.
My experience with writing Eiffel code was a bit
Robert Brown [EMAIL PROTECTED] writes:
In any case, I'm still not sure whether it would be useful to integrate DbC
into Python.
I guess I'm a little confused about what it would mean. Suppose you
want to write a function that looks for a value using binary search
in a sorted list, n =
Carl Banks [EMAIL PROTECTED] wrote:
Python really isn't suitable for in-flight controls for various
reasons, and mission critical concerns is a minor one (systems with
less underlying complexity tend to have fewer failure modes). But
mostly it's raw throughput: Python is just too slow.
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
On Aug 31, 3:18 am, Russ [EMAIL PROTECTED] wrote:
For the record, the guy I
criticized
made ridiculous assertions about DBC.
And that would be me? Oh my! LOL!
This is not nearly as fun as the guy who explained to Steve Holden how
Python works, but still ... ;)
If you are upset about my
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
On Aug 29, 7:21 am, Russ [EMAIL PROTECTED] wrote:
Thanks for that information. That's too bad, because it seems like a
strong positive capability to add to Python. I wonder why the cold
reception. Were there problems with the idea itself or just the
implementation? Or is it just a low
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would still not
be needed since Python provides out of
On Aug 29, 8:45 am, Russ [EMAIL PROTECTED] wrote:
I get the strong impression you don't really understand what
programming by contract is.
I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that
In article [EMAIL PROTECTED],
Russ [EMAIL PROTECTED] wrote:
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is deferred. I did a
On 8/29/07, Russ [EMAIL PROTECTED] wrote:
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it would
Chris Mellon wrote:
On 8/29/07, Russ [EMAIL PROTECTED] wrote:
[...]
If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
On Tue, 28 Aug 2007 23:45:28 -0700, Russ wrote:
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED]
wrote:
Why do you think that would ad a strong positive capability?
To me at least it seems a big fat lot of over-engineering, not
needed in 99% of programs. In the remaining 1%, it
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
On Aug 30, 1:17 am, Dan Stromberg - Datallegro
[EMAIL PROTECTED] wrote:
IMO, putting Programming by Contract into python as part of the language
itself, or as a simple module, is a little bit like a company or
department coming up with a mission statement. It's easy to say that it's
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is deferred. I did a quick search on
comp.lang.python,
but I don't seem to see
Russ wrote:
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is deferred. I did a quick search on
comp.lang.python,
but I
On Aug 28, 9:35 pm, Steven Bethard [EMAIL PROTECTED] wrote:
Russ wrote:
I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status
95 matches
Mail list logo
