Re: Programming by contract.

On 26Feb2023 02:44, Weatherby,Gerard wrote: The discussion of asserts got me thinking about Programming by Contract. Back in the 90s, I had occasion to learn Eiffel programming language. ( https://en.wikipedia.org/wiki/Eiffel_(programming_language) The concepts are intriguing, although

Programming by contract.

The discussion of asserts got me thinking about Programming by Contract. Back in the 90s, I had occasion to learn Eiffel programming language. ( https://en.wikipedia.org/wiki/Eiffel_(programming_language) The concepts are intriguing, although Eiffel itself had barriers to widespread adoption

Re: Programming by Contract

? (*Contstant vigilance!* as Prof Moody would say ;) I know asserts can be turned off, so they obviously won't work for the latter case, and having seen the sample of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying &quo

Re: Programming by Contract

Moody would say ;) I know asserts can be turned off, so they obviously won't work for the latter case, and having seen the sample of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outpu

Re: Programming by Contract

obviously won't work for the latter case, and having seen the sample of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it? ~Ethan~ Hmmm... Well, from

Re: Programming by Contract

ct?   > >>> (*Contstant vigilance!* as Prof Moody  would say ;) > >>> I know asserts can be turned off, so they obviously won't work for   > >>> the latter case, and having seen the sample of pycontract it seems   > >>> it only does its thing during deb

Re: Programming by Contract

they obviously won't work for the latter case, and having seen the sample of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it? ~Ethan~ Hmmm...

Re: Programming by Contract

work for the latter case, and having seen the sample of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it? ~Ethan~ Hmmm... Well, from the (apparently) c

Re: Programming by Contract

le of pycontract it seems it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it? ~Ethan~ Hmmm... Well, from the (apparently) complete lack of interest, I shall take aw

Programming by Contract

ms it only does its thing during debugging. So is Design (Programming) by Contract a fancy way of saying "Document your inputs/outputs!" or is there more to it? ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list

Re: programming by contract using "decorators"

Russ wrote: > Dealing with the arguments was not a trivial matter -- at least not > for me. I had to experiment a bit to get it right. The "getarg" > function is simply a utility for parsing the ordered and keyword > arguments. It's very simple, but if something like this already > exists, please

programming by contract using "decorators"

In the thread I started a few days ago, I was told that "programming by contract," could be done with "decorators." I was skeptical that this was a good approach, but as an exercise, I tried to code it up in a reasonably elegant form. I'd like to think I succeeded -- an

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

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 tim

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

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 li

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

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

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

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 i

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

On Sep 1, 10:05 pm, Russ <[EMAIL PROTECTED]> wrote: > changing the language itself. Someone please correct me if I am wrong, > but I think PEP adds only to the libraries. I meant to write PEP 316, of course. -- http://mail.python.org/mailman/listinfo/python-list

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

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,

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

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

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

On Sep 2, 7:05 am, Russ <[EMAIL PROTECTED]> wrote: > Someone please correct me if I am wrong, > but I think PEP adds only to the libraries. You are wrong, PEPs also add to the core language. Why don't you give a look at the PEP parade on python.org? Michele Simionato -- http://mail.pyth

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

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 mai

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

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 implementatio

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

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 techni

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

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*, bu

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

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

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

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 discu

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

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

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

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

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

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

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

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 b

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

Hendrik van Rooyen wrote: > "Carl Banks" wrote: > >> This is starting to sound silly, people. Critical is a relative term, >> and one project's critical may be anothers mundane. Sure a flaw in your >> flagship product is a critical problem *for your company*, but are you >> really trying to

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

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 >

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

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 s

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

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

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

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

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

On Sat, 01 Sep 2007 10:34:08 +0200, Hendrik van Rooyen 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 compan

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

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

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

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 ar

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

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 eng

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

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

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

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

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

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

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

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 simpl

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

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

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

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 fro

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

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

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

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 exper

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

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 sea

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

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.

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

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 kn

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

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"

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

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 interfac

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

Paul Rubin 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 somethin

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

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 with

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

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 fo

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

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"

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

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 th

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

[EMAIL PROTECTED] (Alex Martelli) writes: > Yeah, good question indeed, and I'm asking myself that -- somebody who > posts to this group in order to attack the reliability of the language > the group is about (and appears to be supremely ignorant about its use > in air-traffic control and for high-

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

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

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

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

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

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

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

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 expe

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

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 relia

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

On Aug 30, 9:41 pm, 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

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

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 bet

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

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 l

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

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 tho

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

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 impor

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

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

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

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

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

> 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

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

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 e

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

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.

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

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 underst

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

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

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

> On Behalf Of Russ > Once you have the conditions in place, all you need to do in > your unit tests is to send inputs to the unit and wait to see > if exceptions are thrown. That sounds a little ambitious to me... However, you may want to look at the typecheck module (you can get it via easy_i

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

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 :

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

lly 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

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

# your code here > > return something > > That looks like new syntax to me. Did I miss your point? > > I have no strong leaning about what the exact syntax should be for > programming by contract. > The syntax you show above seems reasonable, except that I am not s

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

t): >@pre(lambda x : x != 42) >@post(lambda result: result != 42) >@invariant(lambda self: self.x == 42) >def reliable_method(self, x): > # your code here > return something That looks like new syntax to me. Did I miss your point? I have no strong le

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

emaining 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

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

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

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

> Things get vetted *before* they get added to the core, not after. I realize that. I meant that it would get vetted in the process of putting it into the core. That would provide more confidence that it was done the best possible way -- or close to it. -- http://mail.python.org/mailman/listinf

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

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 sup

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

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

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

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

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

> 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

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

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 e

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

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

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

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

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

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

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

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 impressio

  1   2   >