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 time to follow discussions on this group, you'd notice that newcomers are usually welcome. It's not a problem of being an outsider of an insider, and there's nothing clannish (or very few, specially when compared to some other places on usenet), it's mostly a problem with your attitude. And please notice, once again, that I'm not talking about *you* - as a person - but about how you behave(d). (snip) -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ [EMAIL PROTECTED] writes: try: blah blah with as many return statements as you want finally: something that gets executed unconditionally at the end Thanks. I didn't think of that. So design by contract *is* relatively easy to use in Python already. The main issue, I suppose, is one of aesthetics. Do I want to use a lot of explicit function calls for pre and post-conditions and try/ finally blocks in my code to get DbC (not to mention a global variable to enable or disable it)? I still don't understand why you don't like the decorator approach, which can easily implement the above. I personally use Python for its clean syntax and its productivity with my time, so I am certainly not denigrating it. For the RD work I do, I think it is very appropriate. But I did raise a few eyebrows when I first started using it. I used C++ several years ago, and I thought about switching to Ada a few years ago, but Ada just seems to be fading away (which I think is very unfortunate, but that's another story altogether). It seems to be getting displaced by Java, which has some of the same benefits and costs as Ada does. I've gotten interested in static functional languages (including proof assistants like Coq, that can generate certified code from your mechanically checked theorems). But I haven't done anything serious with any of them yet. I think we're in a temporary situation where all existing languages suck (some more badly than others) but the functional languages seem like a more promising direction to get out of this hole. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
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)?
On Sep 1, 11:04 pm, Paul Rubin wrote: I still don't understand why you don't like the decorator approach, which can easily implement the above. Well, maybe decorators are the answer. If a function needs only one decorator for all the conditions and invariants (pre and post- conditions), and if it can just point to functions defined elsewhere (rather than defining everything inline), then perhaps they make sense. I guess I need to read up more on decorators to see if this is possible. In fact, the ideal would be to have just a single decorator type, say contract or self_test, that takes an argument that points to the relevant functions to use for the function that the decorator applies to. Then the actual self-test functions could be pushed off somewhere else, and the footprint on the primary code would be minimal -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Alex Martelli wrote: Ricardo Aráoz [EMAIL PROTECTED] wrote: ... We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, ... You win the argument, and thanks you prove my point. You typically concerned yourself with the technical part of the matter, yet you completely ignored the point I was trying to make. That's because I don't particularly care about the point you were trying to make (either for or against -- as I said, it's a case of ROI for different investments [in either security, or, more germanely to this thread, reliability] rather than of useful/useless classification of the investments), while I care deeply about proper system thinking (which you keep failing badly on, even in this post). And here you start, followed by 'F- at system thinking', 'glib and false assertions', 'falsities', etc. I don't think you meant anything personal, how could you, we don't know each other. But the outcome feels like a personal attack instead of an attack on the ideas exposed. If that's not what you intended, you should check your communication abilities and see what is wrong. If that is what you meant well... So I will not answer your post. I'll let it rest for a while till I don't feel the sting, then I'll re-read it and try to learn as much as I can from your thoughts (thank you for them). And even though some of your thinking process I find objectionable I will not comment on it as I'm sure it will start some new flame exchange which will have a lot to do with ego and nothing to do with python. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
In article [EMAIL PROTECTED], Russ [EMAIL PROTECTED] wrote: Excellent points. As for no strong case for adding new features to Python specifically for design-by-contract, if you mean adding something to language itself, I agree, but I see nothing wrong with adding it to the standard libraries, if that is possible without changing the language itself. Someone please correct me if I am wrong, but I think PEP adds only to the libraries. You're wrong, but even aside from that, libraries need to prove themselves useful before they get added. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important. --Henry Spencer http://www.lysator.liu.se/c/ten-commandments.html -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Fri, 31 Aug 2007 22:18:09 -0300, Jorge Godoy wrote: Russ wrote: Alex, I think you are missing the point. Yes, I'm sure that web searches are critical to Google's mission and commercial success. But the point is that a few subtle bugs cannot destroy Google. If your search engines and associated systems have bugs, you fix them (or simply tolerate them) and continue on. And if a user does not get the results he wants, he isn't likely to die over it -- or even care much. But if this pattern of not getting wanted results is common, then the user will migrate to alternative search engines and this will *kill* the business. Wrong results won't impact ONE search, but many will impact the company business and will be part of the recipe to take it out of business. Online financial transactions are another matter altogether, of course. User won't die, but they will get very irate if they lose money. But I don't think that's what you are talking about here. Lets make someone loose his job and have all his money commitments compromised because of this money lost and we might be talking about people taking their lives. Again, this isn't 100% sure to happen, but it *can* happen. As it happens with a peacemaker: the user won't die if his heart skips one beat, but start skipping a series of them and you're incurring in serious problems. Just because the result isn't immediate it doesn't mean it isn't critical. This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. BTW, I'm not really agreeing with Russ here. His suggestion (that because Python is not used in highly critical systems, it is not suitable for them) is logically flawed. And Alex's point, that Python has a good track record of reliabilty (look at Google's 99.9% uptime) is valid whether Google is a critical system or not. So please leave the laughable comparisons between flight systems and web searches out of it. It's unnecessary and makes Pythoners look bad. Carl Banks (P.S. 99.9% uptime would be a critical flaw in the systems I work on.) -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ [EMAIL PROTECTED] writes: The idea here is that errors in the self-testing code are unlikely to be correlated with errors in the primary code. Hence, you get a sort of multiplying effect on reliability. For example, if the chance of error in the primary code and the self-test code are each 0.01, the chance of an undetected error is approximately 0.01^2 or 0.0001. But I think you give a lot of that back when you turn the checks off. The errors you detect when the checks are enabled are only the ones that result from your test data. Turn off the checks and expose the application to data from a potentially different distribution, and you're back where you started. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Carl Banks pavlmail.com wrote: This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. This really intrigues me - how do you program a dam? - and why is it critical? Most dams just hold water back. Dam design software - well yes that I would agree is critical. Is that what you mean? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sat, 01 Sep 2007 10:34:08 +0200, Hendrik van Rooyen wrote: Carl Banks pavlmail.com wrote: This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. This really intrigues me - how do you program a dam? - and why is it critical? Most dams just hold water back. And some produce electricity. And most if not all can regulate how many water is let through. If something goes wrong the valley behind the dam gets flooded. If this is controlled by a computer you have the need for reliable software. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 29 Aug., 13:45, Russ [EMAIL PROTECTED] wrote: I have not yet personally used it, but I am interested in anything that can help to make my programs more reliable. If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software I'm one of the few (thousand) hard core Eiffel programmers on this world and i can tell you that this would not add to much to python. To get the benefits of it you need to use it together with a runtime that is designed from ground with DBC and a language that is fast enough to be able to check the contracts, if you don't have the latter all you get is a better specification language (which you can write as comments in python). Learn the Eiffel design way and then add assert statements whereever you need them. Works well when i do C/C++ programming and maybe even for script languages - but i never used it for scripts as i don't see a real value here. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Steve Holden wrote: [...] If I can blow my own trumpet briefly, two customers (each using over 25 kLOC I have delivered over the years) ran for two years while I was away in the UK without having to make a single support call. One of the systems was actually locked in a cupboard all that time (though I have since advised that client to at least apply OS patches to bring it up to date). This was achieved by defensive programming, understanding the user requirements and just generally knowing what I was doing. On the one hand, nice work. Made your customers happy and kept them happy. Can't argue with success. On the other hand, 25K lines is tiny by software engineering standards. If a support call would have to go to you, then the project must be small. Software engineering is only a little about an engineer knowing or not knowing what he or she is doing; the bigger problem is that hundreds or thousand of engineers cannot possibly all know what all the others are doing. I work on large and complex systems. If I screw up -- O.K., face facts: *when* I screw up -- the chance of the issue being assigned to me is small. Other engineers will own the problems I cause, while I work on defects in code I've never touched. I wish I could own all my own bugs, but that's not how large and complex systems work. Root-cause analysis is the hard part. By the time we know what went wrong, 99.99% of the work is done. Design-by-contract (or programming-by-contract) shines in large and complex projects, though it is not a radical new idea in software engineering. We pretty much generally agree that we want strong interfaces to encapsulate implementation complexity. That's what design-by-contract is really about. There is no strong case for adding new features to Python specifically for design-by-contract. The language is flexible enough to support optionally-executed pre-condition and post-condition checks, without any extension. The good and bad features of Python for realizing reliable abstraction are set and unlikely to change. Python's consistency and flexibility are laudable, while duck-typing is a convenience that will always make it less reliable than more type-strict languages. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Carl Banks wrote: This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. Who said they were the same? I said that just because it doesn't take lives it doesn't mean it isn't important. I wasn't going to reply to not extend this, but this misunderstanding of your was bugging me. I use Python on systems that deal with human health and wrong calculations may have severe impact on a good sized population. Using Python. As with nuclear reactors, dams, airplanes and so on we have a lot of redundancy and a lot of checkpoints. No one is crazy to take them out or even to remove some kind of dispositive to allow manual intervention at critical points. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Bryan Olson wrote: Steve Holden wrote: [...] If I can blow my own trumpet briefly, two customers (each using over 25 kLOC I have delivered over the years) ran for two years while I was away in the UK without having to make a single support call. One of the systems was actually locked in a cupboard all that time (though I have since advised that client to at least apply OS patches to bring it up to date). This was achieved by defensive programming, understanding the user requirements and just generally knowing what I was doing. On the one hand, nice work. Made your customers happy and kept them happy. Can't argue with success. On the other hand, 25K lines is tiny by software engineering standards. If a support call would have to go to you, then the project must be small. Software engineering is only a little about an engineer knowing or not knowing what he or she is doing; the bigger problem is that hundreds or thousand of engineers cannot possibly all know what all the others are doing. I agree that programming-in-the-large brings with it problems that aren't experienced in smaller scale projects such as the ones I mentioned. I work on large and complex systems. If I screw up -- O.K., face facts: *when* I screw up -- the chance of the issue being assigned to me is small. Other engineers will own the problems I cause, while I work on defects in code I've never touched. I wish I could own all my own bugs, but that's not how large and complex systems work. Root-cause analysis is the hard part. By the time we know what went wrong, 99.99% of the work is done. This is the kind of realism I like to see in engineering. I am always suspicious when any method is promoted as capable of reducing the error rate to zero. Design-by-contract (or programming-by-contract) shines in large and complex projects, though it is not a radical new idea in software engineering. We pretty much generally agree that we want strong interfaces to encapsulate implementation complexity. That's what design-by-contract is really about. There is no strong case for adding new features to Python specifically for design-by-contract. The language is flexible enough to support optionally-executed pre-condition and post-condition checks, without any extension. The good and bad features of Python for realizing reliable abstraction are set and unlikely to change. Python's consistency and flexibility are laudable, while duck-typing is a convenience that will always make it less reliable than more type-strict languages. Python's dynamic nature certainly makes it more difficult to reason about programs in any formal sense. I've always thought of it as a pragmatist's language, and we need to be pragmatic about the downside as well as the upside. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Hendrik van Rooyen wrote: Carl Banks pavlmail.com wrote: This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. This really intrigues me - how do you program a dam? - and why is it critical? Most dams just hold water back. Dam design software - well yes that I would agree is critical. Is that what you mean? - Hendrik Yup! He was referring to that Damn design software. Just as almost everyone has at one time or another. ;c) -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Carl Banks a écrit : This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. 20 years ago, there was *no* computer at all in nuclear reactors. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Hendrik van Rooyen [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | This really intrigues me - how do you program a dam? - and why is it | critical? | | Most dams just hold water back. Most big dams also generate electricity. Even without that, dams do not just hold water back, they regulate the flow over a year or longer cycle. A full dam is great for power generation and useless for flood control. An empty dam is great for flood control and useless for power generation. So both power generation and bypass release must be regulated in light of current level, anticipated upstream precipitation, and downstream obligations. Downstream obligations can include both a minimum flow rate for downstream users and a maximum rate so as to not flood downstream areas. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Ricardo Aráoz [EMAIL PROTECTED] wrote: ... We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, Not true (not even for security, much less for reliability which is what's being discussed here). It's easy to see how this assertion of yours is totally wrong in many ways... Example 1: a toy system made up of subsystem A (which has a probability of 90% of working right) whose output feeds into subsystem B (which has a probability of 80% of working right). A's failures and B's faliures are statistically independent (no common-mode failures, c). The ``level of goodness'' (probability of working right) of the weakest component, B, is 80%; but the whole system has a ``level of goodness'' (probability of working right) of just 72%, since BOTH subsystems must work right for the whole system to do so. 72 != 80 and thus your assertion is false. More generally: subsystems in series with independent failures can produce a system that's weaker than its weakest component. Example 2: another toy system made up of subsystems A1, A2 and A3, each trying to transform the same input supplied to all of them into a 1 bit result; each of these systems works right 80% of the time, statistically independently (no common-mode failures, c). The three subsystems' results are reconciled by a simple majority-voting component M which emits as the system's result the bit value that's given by two out of three of the Ai subsystems (or, of course, the value given unanimously by all) and has extremely high reliability thanks to its utter simplicity (say 99.9%, high enough that we can ignore M's contribution to system failures in a first-order analysis). The whole system will fail when all Ai fail together (probability 0.2**3) or when 2 out of them fail while the hird one is working (probability 3*0.8*0.2**2): 0.2**3+3*0.2**2*0.8 0.10404 So, the system as a whole has a level of goodness (probability of working right) of almost 90% -- again different from the weakest component (each of the three Ai's), in this case higher. More generally: subsystems in parallel (arranged so as to be able to survive the failure of some subset) with indipendent failures can produce a system that's stronger than its weakest component. Even in the field of security, which (changing the subject...) you specifically refer to, similar considerations apply. If your assertion was correct, then removing one component would never WEAKEN a system's security -- it might increase it if it was the weakest, otherwise it would leave it intact. And yet, a strong and sound tradition in security is to require MULTIPLE components to be all satisfied e.g. for access to secret information: e.g. the one wanting access must prove their identity (say by retinal scan), possess a physical token (say a key) AND know a certain secret (say a password). Do you really think that, e.g., removing the need for the retinal scan would make the system's security *STRONGER*...? It would clearly weaken it, as a would-be breaker would now need only to purloin the key and trick the secret password out of the individual knowing it, without the further problem of falsifying a retinal scan successfully. Again, such security systems exist and are traditional exactly because they're STRONGER than their weakest component! So, the implication accompanying your assertion, that strenghtening a component that's not the weakest one is useless, is also false. It may indeed have extremely low returns on investment, depending on system's structure and exact circumstances, but then again, it may not; nothing can be inferred about this ROI issue from the consideration in question. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ [EMAIL PROTECTED] wrote: ... the inputs. To test the post-conditions, you just need a call at the bottom of the function, just before the return, ... there's nothing to stop you putting the calls before every return. Oops! I didn't think of that. The idea of putting one before every return certainly doesn't appeal to me. So much for that idea. try: blah blah with as many return statements as you want finally: something that gets executed unconditionally at the end You'll need some convention such as all the return statements are of the same form ``return result'' (where the result may be computed differently each time), but that's no different from the conventions you need anyway to express such things as ``the value that foobar had at the time the function was called''. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Alex Martelli wrote: Ricardo Aráoz [EMAIL PROTECTED] wrote: ... We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, Not true (not even for security, much less for reliability which is what's being discussed here). It's easy to see how this assertion of yours is totally wrong in many ways... Example 1: a toy system made up of subsystem A (which has a probability of 90% of working right) whose output feeds into subsystem B (which has a probability of 80% of working right). A's failures and B's faliures are statistically independent (no common-mode failures, c). The ``level of goodness'' (probability of working right) of the weakest component, B, is 80%; but the whole system has a ``level of goodness'' (probability of working right) of just 72%, since BOTH subsystems must work right for the whole system to do so. 72 != 80 and thus your assertion is false. More generally: subsystems in series with independent failures can produce a system that's weaker than its weakest component. Example 2: another toy system made up of subsystems A1, A2 and A3, each trying to transform the same input supplied to all of them into a 1 bit result; each of these systems works right 80% of the time, statistically independently (no common-mode failures, c). The three subsystems' results are reconciled by a simple majority-voting component M which emits as the system's result the bit value that's given by two out of three of the Ai subsystems (or, of course, the value given unanimously by all) and has extremely high reliability thanks to its utter simplicity (say 99.9%, high enough that we can ignore M's contribution to system failures in a first-order analysis). The whole system will fail when all Ai fail together (probability 0.2**3) or when 2 out of them fail while the hird one is working (probability 3*0.8*0.2**2): 0.2**3+3*0.2**2*0.8 0.10404 So, the system as a whole has a level of goodness (probability of working right) of almost 90% -- again different from the weakest component (each of the three Ai's), in this case higher. More generally: subsystems in parallel (arranged so as to be able to survive the failure of some subset) with indipendent failures can produce a system that's stronger than its weakest component. Even in the field of security, which (changing the subject...) you specifically refer to, similar considerations apply. If your assertion was correct, then removing one component would never WEAKEN a system's security -- it might increase it if it was the weakest, otherwise it would leave it intact. And yet, a strong and sound tradition in security is to require MULTIPLE components to be all satisfied e.g. for access to secret information: e.g. the one wanting access must prove their identity (say by retinal scan), possess a physical token (say a key) AND know a certain secret (say a password). Do you really think that, e.g., removing the need for the retinal scan would make the system's security *STRONGER*...? It would clearly weaken it, as a would-be breaker would now need only to purloin the key and trick the secret password out of the individual knowing it, without the further problem of falsifying a retinal scan successfully. Again, such security systems exist and are traditional exactly because they're STRONGER than their weakest component! So, the implication accompanying your assertion, that strenghtening a component that's not the weakest one is useless, is also false. It may indeed have extremely low returns on investment, depending on system's structure and exact circumstances, but then again, it may not; nothing can be inferred about this ROI issue from the consideration in question. Alex You win the argument, and thanks you prove my point. You typically concerned yourself with the technical part of the matter, yet you completely ignored the point I was trying to make. That is that in real world applications formally proving the application is not only an enormous resource waster but it also pays very little if at all. I think most cases will fall under point (1) of your post, and as so many other not formally proven subsystems are at work at the same time there will be hardly any gain in doing it. Point (2) of your post would be my preferred solution, and what is usually done in hardware. In the third part of your post, regarding security, I think you went off the road. The weakest component would not be one of the requisites of access, the weakest component I was referring to would be an actual APPLICATION, e.g. an ftp server. In that case, if you have several applications running your security will be the security of the weakest of them. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sat, 01 Sep 2007 08:38:38 -0300, Jorge Godoy wrote: Carl Banks wrote: This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. Who said they were the same? The word I used was comparable. I said that just because it doesn't take lives it doesn't mean it isn't important. I wasn't going to reply to not extend this, but this misunderstanding of your was bugging me. Well, I wasn't talking about importance, actually. Importance is really a matter for sociologists. Perhaps you can find a sociologist who would agree that a health monitoring system is more important than an aircraft control system (probably wouldn't be too hard, actually, especially if it's a military aircraft). I could hardly argue with that. But, frankly, importance to society is only a small part of what determines criticalness of the application; and criticalness is what factors into a decision on what programming language to use. Here are some of the main factors that determine criticalness: How much time is there between failure and catastrophe? What is the cost (societal and/or economic) of a catastrophe? How recoverable is a failure? What is the degree of difficulty of the programming? Do small errors accumulate? How many government regulations does the code have to meet? What is the acceptable failure rate before an application is allowed to deploy? How much money is being spent to ensure flawless operation before it even deploys? By these criteria, Google web search, your health monitoring system, a bank transaction system, etc., hardly compare to something like aircraft control. I'm sorry. I use Python on systems that deal with human health and wrong calculations may have severe impact on a good sized population. Using Python. Cool. Not that, by itself, would be enough to make me feel good about Python on airplanes. As with nuclear reactors, dams, airplanes and so on we have a lot of redundancy and a lot of checkpoints. No one is crazy to take them out or even to remove some kind of dispositive to allow manual intervention at critical points. Really? I must work with crazy people then, because we are working on a full authority control system: no bypassing the computer, no manual intervention. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sat, 01 Sep 2007 17:19:49 +0200, Pierre Hanser wrote: Carl Banks a écrit : This is starting to sound silly, people. Critical is a relative term, and one project's critical may be anothers mundane. Sure a flaw in your flagship product is a critical problem *for your company*, but are you really trying to say that the criticalness of a bad web search is even comparable to the most important systems on airplanes, nuclear reactors, dams, and so on? Come on. 20 years ago, there was *no* computer at all in nuclear reactors. But they had electronic (analog) systems that were (supposedly) just as heavily regulated and scrutinized as the digital computers of today; and were a lot more scrutinized than, say, the digital computers that banks were using. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Ricardo Aráoz [EMAIL PROTECTED] wrote: ... We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, ... You win the argument, and thanks you prove my point. You typically concerned yourself with the technical part of the matter, yet you completely ignored the point I was trying to make. That's because I don't particularly care about the point you were trying to make (either for or against -- as I said, it's a case of ROI for different investments [in either security, or, more germanely to this thread, reliability] rather than of useful/useless classification of the investments), while I care deeply about proper system thinking (which you keep failing badly on, even in this post). In the third part of your post, regarding security, I think you went off the road. The weakest component would not be one of the requisites of access, the weakest component I was referring to would be an actual APPLICATION, Again, F- at system thinking: a system's components are NOT just applications (what's the alternative to their being actual, btw?), nor is it necessarily likely that an application would be the weakest one of the system's components (these wrong assertions are in addition to your original error, which you keep repeating afterwards). For example, in a system where access is gained *just* by knowing a secret (e.g., a password), the weakest component is quite likely to be that handy but very weak architectural choice -- or, seen from another viewpoint, the human beings that are supposed to know that password, remember, and keep it secret. If you let them choose their password, it's too likely to be fred or other easily guessable short word; if you force them to make it at least 8 characters long, it's too likely to be fredfred; if you force them to use length, mixed case and digits, it's too likely to be Fred2Fred. If you therefore decide that passwords chosen by humans are too weak and generate one for them, obtaining, say, FmZACc2eZL, they'll write it down (perhaps on a post-it attached to their screen...) because they just can't commit to memory a lot of long really-random strings (and nowadays the poor users are all too likely to need to memorize far too many passwords). A clever attacker has many other ways to try to steal passwords, from social engineering (pose as a repair person and ask the user to reveal their password as a prerequisite of obtaining service), to keystroke sniffers of several sorts, fake applications that imitate real ones and steal the password before delegating to the real apps, etc, etc. Similarly, if all that's needed is a physical token (say, some sort of electronic key), that's relatively easy to purloin by traditional means, such as pickpocketing and breaking-and-entering; certain kind of electronic keys (such as the passive unencrypted RFID chips that are often used e.g. to control access to buildings) are, in addition, trivially easy to steal by other (technological) means. Refusing to admit that certain components of a system ARE actually part of the system is weak, blinkered thinking that just can't allow halfway decent system design -- be that for purposes of reliability, security, availability, or whatever else. Indeed, if certain part of the system's architecture are OUTSIDE your control (because you can't redesign the human mind, for example;-), all the more important then to make them the focus of the whole design (since you must design AROUND them, and any amelioration of their weaknesses is likely to have great ROI -- e.g., if you can make the users take a 30-minutes short course in password security, and accompany that with a password generator that makes reasonably memorable though random ones, you're going to get substantial returns on investment in any password-using system's security). e.g. an ftp server. In that case, if you have several applications running your security will be the security of the weakest of them. Again, false as usual, and for the same reason I already explained: if your system can be broken by breaking any one of several components, then it's generally WEAKER than the weakest of the components. Say that you're running on the system two servers, an FTP one that can be broken into by 800 hackers in the world, and a SSH one that can only be broken into by 300 hackers in the world; unless every single one of the hackers who are able to break into the SSH server is *also* able to break into the FTP one (a very special case indeed!), there are now *MORE* than 800 hackers in the world that can break into your system as a whole -- in other words, again and no matter how often you repeat falsities to the contraries without a shred of supporting argument, your assertion is *FALSE*, and in this case your security is *WEAKER* than the security of the weaker of the two components. I do not really much care what point(s) you are trying to make through your
Re: status of Programming by Contract (PEP 316)?
On Sep 1, 4:25 am, Bryan Olson Design-by-contract (or programming-by-contract) shines in large and complex projects, though it is not a radical new idea in software engineering. We pretty much generally agree that we want strong interfaces to encapsulate implementation complexity. That's what design-by-contract is really about. There is no strong case for adding new features to Python specifically for design-by-contract. The language is flexible enough to support optionally-executed pre-condition and post-condition checks, without any extension. The good and bad features of Python for realizing reliable abstraction are set and unlikely to change. Python's consistency and flexibility are laudable, while duck-typing is a convenience that will always make it less reliable than more type-strict languages. Excellent points. As for no strong case for adding new features to Python specifically for design-by-contract, if you mean adding something to language itself, I agree, but I see nothing wrong with adding it to the standard libraries, if that is possible without changing the language itself. Someone please correct me if I am wrong, but I think PEP adds only to the libraries. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sep 1, 6:51 pm, [EMAIL PROTECTED] (Alex Martelli) try: blah blah with as many return statements as you want finally: something that gets executed unconditionally at the end Thanks. I didn't think of that. So design by contract *is* relatively easy to use in Python already. The main issue, I suppose, is one of aesthetics. Do I want to use a lot of explicit function calls for pre and post-conditions and try/ finally blocks in my code to get DbC (not to mention a global variable to enable or disable it)? I suppose if I want it badly enough, I will. But I also happen to be a bit obsessive about the appearance of my code, and this does complicate it a bit. The nice thing about having it in the doc string (as per PEP 316) is that, while it is inside the function, it is also separate from the actual code in the function. I like that. As far as I am concerned, the self-test code shouldn't be tangled up with the primary code. By the way, I would like to make a few comments about the reliability of Python code. Apparently I offended you the other day by claiming or implying that Python code is inherently unreliable. I think it is probably possible to write very reliable code in Python, particularly for small to medium sized applications, but you probably need top notch software engineers to do it. And analyzing code or *proving* that a program is correct is technically harder without static typing. In highly regulated safety critical domains, you need more than just reliable code; you need to *demonstrate* or *prove* the reliability somehow. I personally use Python for its clean syntax and its productivity with my time, so I am certainly not denigrating it. For the RD work I do, I think it is very appropriate. But I did raise a few eyebrows when I first started using it. I used C++ several years ago, and I thought about switching to Ada a few years ago, but Ada just seems to be fading away (which I think is very unfortunate, but that's another story altogether). In any case, when you get right down to it, I probably don't know what the hell I'm talking about anyway, so I will bring this rambling to a merciful end. On, one more thing. I see that the line wrapping on Google Groups is finally working for me after many months. Fantastic! I can't help but wonder if my mentioning it to you a few days ago had anything to do with it. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sep 2, 7:05 am, Russ [EMAIL PROTECTED] wrote: Someone please correct me if I am wrong, but I think PEP adds only to the libraries. You are wrong, PEPs also add to the core language. Why don't you give a look at the PEP parade on python.org? Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Sep 1, 10:44 pm, Russ [EMAIL PROTECTED] wrote: On, one more thing. I see that the line wrapping on Google Groups is finally working for me after many months. Fantastic! I can't help but wonder if my mentioning it to you a few days ago had anything to do with it. Well, it's working on the input side anyway. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Python really isn't suitable for in-flight controls for various reasons, and mission critical concerns is a minor one (systems with Do you know anything about the FAA certification process for flight- critical systems? I am not an expert on it, but I know it is very expensive. If I am not mistaken, getting such code certified is more expensive than developing it in the first place. Why would that be so if, as you claim, mission critical concerns is a minor one? -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Fri, 31 Aug 2007 01:15:04 -0400, Roy Smith wrote: Carl Banks [EMAIL PROTECTED] wrote: Python really isn't suitable for in-flight controls for various reasons, and mission critical concerns is a minor one (systems with less underlying complexity tend to have fewer failure modes). But mostly it's raw throughput: Python is just too slow. Flight control computers have to be powerful enough make a ton of mathematical calculations in a matter of milliseconds, and under strict weight and power constraints. The cost of running 100 times slower than optimal is just too high. I'm not convinced that's true for all avionics uses. Of course it's not. I was talking about flight control, not avionics in general. (Perhaps when single-engine Cessnas go digital we'll even see flight controllers in Python.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 30, 7:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote: Russ [EMAIL PROTECTED] wrote: ... programs. Any idea how much Python is used for flight control systems in commercial transport aircraft or jet fighters? Hi Alex. I've always enjoyed your Piggies talks at Google (although I missed he last one because I was out of town). I'm disappointed to see that you seem to have taken personal offense from remarks I made to someone else who attacked me first. I will take issue with some of your remarks, bit none of it is intended to be personal, and I sincerely hope you don't take it that way. Are there differences in reliability requirements between the parts of such control systems that run on aircraft themselves, and those that run in airports' control towers? Because Python *IS* used in the latter case, cfr http://www.python.org/about/success/frequentis/ ... if on-plane control SW requires hard-real-time response, that might be a more credible reason why Python would be inappropriate (any garbage collected language is NOT a candidate for hard-real-time SW!) than your implied aspersions against Python's reliability. I've seen that site before. They have a nice product that was developed in Python, but it is not clear to me that is actually safety-critical. It appears to be a GUI designer for displays at air traffic control towers. I can't tell if this is just a development tool, or if it the python-based product is actually used directly by controllers. Also, this product does not seem to actually display aircraft to controllers. It seems to be more of a semi-static display of runway conditions. Not to minimize its importance, but I don't know if this product actually qualifies as safety critical, and if it does, it probably does so only marginally. According to http://uptime.pingdom.com/site/month_summary/site_name/www.google.com, Google's current uptime is around 99.99%, with many months at 100% and a few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW, and in real-world conditions where power can go away, network cables can accidentally get cut, etc. I'm Uber Tech Lead for Production Systems at Google -- i.e., the groups I uber-lead are responsible for some software which (partly by automating things as much as possible) empowers our wondrous Site Reliability Engineers and network specialists to achieve that uptime in face of all the Bad Stuff the world can and does throw at us. Guess what programming language I'm a well-known expert of...? I certainly cannot deny the success of Google, but I don't think that a high uptime with thousands of servers is comparable to reliable safety-critical software. You can't put thousands of flight management computers on an airplane and just switch over to another as they go fail. And if a web server gives bogus results nobody worries much, but if a flight computer gives bogus outputs, some people worry a lot. By the way, I use Google Groups, and it has a few annoying glitches. For example, I couldn't read your post without scrolling horizontally. With all the money and manpower at Google's disposal, couldn't you fix that problem? Another problem I have had for months is that when I write a message to post, I get no auto scrolling, so I have to add manual line breaks to keep the text from running out of the window -- then the reader sees all those ugly misplaced line breaks in the output. These are just annoyances, but why hasn't Google fixed them yet? The point I am trying to make is that, while Google does great things, and is very successful commercially, the quality of its code could certainly use some improvement. Microsoft is also very successful commercially, but certainly you wouldn't argue that is is a result of the quality of its software, I hope. I may have a simplistic view, but I have always thought that the requirements of most Google code are the very antithesis of the requirements of safety critical code. When I do a search, I fully expect most of the results to be crap. It's a scattershot approach. If I get one good result, I am usually happy. Safety critical software is exactly the opposite: if you get one *bad* result, you could be in a heap of something nasty. The important question is this: why do I waste my time with bozos like you? Yeah, good question indeed, and I'm asking myself that -- somebody who posts to this group in order to attack the reliability of the language the group is about (and appears to be supremely ignorant about its use I am sorry that you took offense at my pointing out the weaknesses of Python. It's a great language for certain kinds of applications, but it is not necessarily appropriate for everything. I am personally using it for prototyping a safety critical system that, if it is ultimately fielded, will affect the safety of millions of people, including you. However, my Python prototype is for research and design purposes. The ultimate
Re: status of Programming by Contract (PEP 316)?
On Thu, 30 Aug 2007 22:56:54 -0700, Russ wrote: Python really isn't suitable for in-flight controls for various reasons, and mission critical concerns is a minor one (systems with Do you know anything about the FAA certification process for flight- critical systems? I am not an expert on it, but I know it is very expensive. If I am not mistaken, getting such code certified is more expensive than developing it in the first place. Why would that be so if, as you claim, mission critical concerns is a minor one? I made no such claim; you misconstrued what I wrote. I wrote that mission critical concerns are a minor reason why Python is not used, not that mission critical concerns were minor. As a matter of fact, FAA cert is a major pain, and they unit test the hell out of everything. I'm not aware of any reason why Python couldn't be certified if it passed the tests, but it likely wouldn't pass as easily as a compiled language. OTOH, spiffy features like design-by- contract aren't going to improve your chances of getting FAA cert, either. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : Pre and post conditions applying to the class ? Now that's an interesting concept. IIRC, Eiffels pre and post conditions only apply to methods, and I fail to see how they could apply to a class. But since you're an expert on the subject, I don't doubt you'll enlighten us ? I made a simple mistake. Excuse me. Oh wait ... aren't you one of the sensitivity police who laid into me for criticizing someone else. Nope, I'm one of the regular citizens here that tried to make you realize you were acting as an arrogant clueless newbie. For the record, the guy I criticized made ridiculous assertions about DBC. For the record, the guy you treaded as he was a retarted knows much more than you about both Python and DbC. Thinking that someone is ignorant or ridiculous because he does not happen to share your opinions on some subject is certainly not what's I'd call an intelligent, civilized, respectful attitude. All I did was to make a simple mistake about an inconsequential matter. All you did was persisting on being arrogant while showing your lack of knowledge on both Python and DbC. No, pre and post conditions obviously don't apply to classes, but all I said was that that's how it appeared to me at first glance. If you are upset about my criticism of one of your colleagues, please tell him to quite making outrageous assertions about something he obviously knows little about. I'm not upset. I'm actually trying to help you realizing the dumbness of your attitude. But I'm afraid this is going to be a lost cause... -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. And they are probably right. And they are obviously wrong, by empiric experience. I don't think you understand what they mean by reliable programs. I think you should stop over-estimating yourself, and start realizing that there are quite a lot of experimented programmers here. The important question is this: why do I waste my time with bozos like you? The same question is probably crossing the mind of quite a lot of people here - but the 'bozo' might not be who you think. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 31, 10:02 am, Russ [EMAIL PROTECTED] wrote: Hi Alex. I've always enjoyed your Piggies talks at Google (although I missed he last one because I was out of town). I'm disappointed to see that you seem to have taken personal offense from remarks I made to someone else who attacked me first. I am curious. Why do you think I attacked you? The conversion went as follows: On Aug 29, 7:21 am, Russ [EMAIL PROTECTED] wrote: Thanks for that information. That's too bad, because it seems like a strong positive capability to add to Python. I wonder why the cold reception. Were there problems with the idea itself or just the implementation? Or is it just a low priority? me: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. Basically you said I think DbC is good and I said I don't think so. I would not call that an attack. If you want to see an attack, wait for Alex replying to you observations about the low quality of code at Google! ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
[EMAIL PROTECTED] (Alex Martelli) writes: Yeah, good question indeed, and I'm asking myself that -- somebody who posts to this group in order to attack the reliability of the language the group is about (and appears to be supremely ignorant about its use in air-traffic control and for high-reliability mission-critical applications such as Google's Production Systems software) might well be considered not worth responding to. OTOH, you _did_ irritate me enough that I feel happier for venting in response;-) Hi Alex, I'm a little confused: does Production Systems mean stuff like the Google search engine, which (as you described further up in your message) achieves its reliability at least partly by massive redundancy and failover when something breaks? In that case why is it so important that the software be highly reliable? Is a software fault really worse than a hardware fault, especially if it's permissible to sometimes let a transaction (like a search query) go uncompleted (e.g. by displaying a try again later message)? If you get 1 billion queries in a month and a half dozen of them don't complete (e.g. they give empty or incorrect results when there are some good hits they should display) but the server is never actually down, can you still claim 100% uptime? There's a philosophy in Erlang described as let it crash, i.e. programmers are told NOT to program defensively such as by checking inputs for validity. Instead they should just rely on the fault tolerance and process restart stuff to get things going again if their process fails. Similarly if the Google search software hits some fatal condition once in a while, maybe it's enough to just treat it as a crashed box and let the failover mechanisms handle the problem. Of course then there's a second level system to manage the restarts that has to be very reliable, but it doesn't have to deal with much weird concocted input the way that a public-facing internet application has to. Therefore I think Russ's point stands, that we're talking about a different sort of reliability in these highly redundant systems, than in the systems Russ is describing. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Michele Simionato [EMAIL PROTECTED] writes: http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page... That paper contains only a good think: a link to the contrarian view http://home.flash.net/~kennieg/ariane.html#s3.1.5 I like the contrarian article much better than the Eiffel sales pitch. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? No, they are not formally proven correct (too complicated for that), but I believe they are certified to a higher level than your typical compiler. I think that Ada compilers used for certain safety-critical applications must meet higher standards than, say, GNU Ada, for example. And the OS in which those programs operate, are they also formally proven correct? Same as above, if I am not mistaken. And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? I think the microprocessors used for flight control, for example, are certified to a higher level than standard microprocessors. How would you prove a power supply to be correct? I'm sure they meet higher reliability standards too. In that case why don't we just 'certify to a higher level' the programs and get done with this formal proofs? We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, so either we formally prove all those other very important components (OS gets MUCH more use than the program (the program uses it for almost every other action)) or get done with the whole fuss. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Ricardo Aráoz [EMAIL PROTECTED] writes: In that case why don't we just 'certify to a higher level' the programs and get done with this formal proofs? We should remember that the level of security of a 'System' is the same as the level of security of it's weakest component, so either we formally prove all those other very important components (OS gets MUCH more use than the program (the program uses it for almost every other action)) or get done with the whole fuss. This url has some info on the topic of certification etc.: http://www.dwheeler.com/essays/high-assurance-floss.html -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote: Russ wrote: Yes, thanks for reminding me about that. With SPARK Ada, it is possible for some real (non-trivial) applications to formally (i.e., mathematically) *prove* correctness by static analysis. I doubt that is possible without static declarative type- checking. SPARK Ada is for applications that really *must* be correct or people could die. I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? And the OS in which those programs operate, are they also formally proven correct? And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? Who watches the watchmen? The contracts are composed by the programmers writing the code. Is it likely that the same person who wrote a buggy function will know the right contract? -- Neil Cerutti The third verse of Blessed Assurance will be sung without musical accomplishment. --Church Bulletin Blooper -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Paul Rubin http://[EMAIL PROTECTED] wrote: ... Hi Alex, I'm a little confused: does Production Systems mean stuff like the Google search engine, which (as you described further up in your message) achieves its reliability at least partly by massive redundancy and failover when something breaks? The infrastructure supporting that engine (and other things), yes. In that case why is it so important that the software be highly reliable? Is a software Think common-mode failures: if a program has a bug, so do all identical copies of that program. Redundancy works for cheap hardware because the latter's unreliability is essentially free of common-mode failures (when properly deployed): it wouldn't work against a design mistake in the hardware units. Think of the famous Pentium division bug: no matter how many redundant but identical such buggy CPUs you place in parallel to compute divisions, in the error cases they'll all produce the same wrong results. Software bugs generally work (or, rather, fail to work;-) similarly to hardware design bugs. There are (for both hw and sw) also classes of mistakes that don't quite behave that way -- occasional glitches that are not necessarily repeatable and are heavily state-dependent (race conditions in buggy multitasking SW, for example; and many more examples for HW, where flaky behavior may be triggered by, say, temperature situations). Here, from a systems viewpoint, you might have a system that _usually_ says that 10/2 is 5, but once in a while says it's 4 instead (as opposed to the Pentium division bug case where it would always say 4) -- this is much more likely to be caused by flaky HW, but might possibly be caused by the SW running on it (or the microcode in between -- not that it makes much of a difference one way or another from a systems viewpoint). Catching such issues can, again, benefit from redundancy (and monitoring, watchdog systems, health and sanity checks running in the background, c). Quis custodiet custodes is an interesting problem here, since bugs or flakiness in the monitoring/watchdog infrastructure have the potential to do substantial global harm; one approach is to invest in giving that infrastructure an order of magnitude more reliability than the systems it's overseeing (for example by using more massive and *simple* redundancy, and extremely straightforward architectures). There's ample literature in the matter, but it absolutely needs a *systems* approach: focusing just on the HW, just on the SW, or just on the microcode in-between;-), just can't help much. some good hits they should display) but the server is never actually down, can you still claim 100% uptime? I've claimed nothing (since all such measurements and methodologies would no doubt be considered confidential unless and until cleared for publication -- this has been done for a few whitepapers about some aspects of Google's systems, but never to the best of my knowledge for the metasystem as a whole), but rather pointed to http://uptime.pingdom.com/site/month_summary/site_name/www.google.com, a publically available site which does publish its methodology (at http://uptime.pingdom.com/general/methodology); summarizing, as they have no way to check that the results are right for the many sites they keep an eye on, they rely on the HTTP result codes (as well as validity of HTTP headers returned, and of course whether the site does return a response at all). problem. Of course then there's a second level system to manage the restarts that has to be very reliable, but it doesn't have to deal with much weird concocted input the way that a public-facing internet application has to. Indeed, Production Systems' software does *not* have to deal with input from the general public -- it's infrastructure, not user-facing applications (except in as much as the users are Google engineers or operators, say). IOW, it's *exactly* the code that has to be very reliable (nice to see that we agree on this;-), and therefore, if as you then said Russ's point stands, would NOT be in Python -- but it is. So, I disagree about the standing status of his so-called point. Therefore I think Russ's point stands, that we're talking about a different sort of reliability in these highly redundant systems, than in the systems Russ is describing. Russ specifically mentioned *mission-critical applications* as being outside of Python's possibilities; yet search IS mission critical to Google. Yes, reliability is obtained via a systems approach, considering HW, microcode, SW, and other issues yet such as power supplies, cooling units, network cables, etc, not as a single opaque big box but as an articulated, extremely complex and large system that needs testing, monitoring, watchdogging, etc, at many levels -- there is no other real way to make systems reliable (you can't do it by just looking at components in isolation). Note that this does have costs and therefore it needs to be
Re: status of Programming by Contract (PEP 316)?
Michele Simionato [EMAIL PROTECTED] wrote: ... I would not call that an attack. If you want to see an attack, wait for Alex replying to you observations about the low quality of code at Google! ;) I'm not going to deny that Google Groups has glitches, particularly in its user interface (that's why I'm using MacSOUP instead, even though Groups, were it perfect, would offer me a lot of convenience). We have a LOT of products (see http://www.google.com/intl/en/options/index.html, plus a few more at http://labs.google.com/; http://en.wikipedia.org/wiki/List_of_Google_products for an overview, http://searchengineland.com/070220-091136.php for a list of more lists...), arguably too many in the light of the It's best to do one thing really, really well ``thing we've found to be true''; given the 70-20-10 rule we use (we spend 70% of our resources on search and ads [and of course infrastructure supporting those;-)], 20% on adjacent businesses such as News, Desktop and Maps, 10% on all the rest combined), products in the other (10%) category may simply not receive sufficient time, resources and attention. We've recently officially raised Apps to the status of a third pillar for Google (after Search and Ads), but I don't know which of our many products are officially within these pillar-level Apps -- maybe a good starting hint is what's currently included in the Premier Edition of Google Apps, i.e.: Gmail (with 99.9% uptime guarantee), Google Talk, Google Calendar, Docs Spreadsheets, Page Creator and Start Page. I do notice that Google Groups is currently not in that elite (but then, neither are other products we also offer in for-pay editions, such as Google Earth and Sketchup) but I have no insider information as to what this means or portends for the future (of course not: if I _did_ have insider information, I could not talk about the subject!-). Notice, however, that none of these points depend on use of Python vs (or side by side with) other programming languages, DbC vs (or side by side with) other methodologies, and other such technical and technological issues: rather, these are strategical problems in the optimal allocation of resources that (no matter how abundant they may look on the outside) are always scarce compared to the bazillion ways in which they _could_ be employed -- engineers' time and attention, machines and networking infrastructure, and so forth. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? No, they are not formally proven correct (too complicated for that), but I believe they are certified to a higher level than your typical compiler. I think that Ada compilers used for certain safety-critical applications must meet higher standards than, say, GNU Ada, for example. And the OS in which those programs operate, are they also formally proven correct? Same as above, if I am not mistaken. And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? I think the microprocessors used for flight control, for example, are certified to a higher level than standard microprocessors. How would you prove a power supply to be correct? I'm sure they meet higher reliability standards too. ... I believe ..., ... if I am not mistaken, I think Well, all this certainty you are expressing will surely allow this bozo to sleep more soundly in his bed. Frankly I am getting a little tired of they way you are unable to even recognize that your readers may well have a sensible appreciation of the difficulties about which you write. As has been pointed out already, many readers here are extremely experienced programmers. You said in an earlier post that's not an insult, but that isn't really up to you to decide. If it gives offense then it probably is, whether it was intended to do so or not. You don't seem to appreciate the insulting nature of your tone, and calling people bozos is not likely to endear you to most c.l.py readers since it comes off as arrogant. Given that you now profess no absolute certainty on fairly simple matters connected to safety-critical systems I wish you'd step down off your platform and join the rest of us. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Michele Simionato wrote: I am curious. Why do you think I attacked you? The conversion went as follows: I don't think you attacked me. I was referring to another person, who apparently came to your defense and *did* attack me. For the record, I apologize for saying that you don't seem to know what DbC is. I shouldn't have made it personal. I should have just made the points I made and let them stand on their own. Having said that, I think that some of the statements you made were clearly excessive. Unit testing is a thousand times better than DbC? How could that possibly be? As I tried to explain, DbC can be *used* for unit testing and *also* for integrated system testing. I would not call that an attack. If you want to see an attack, wait for Alex replying to you observations about the low quality of code at Google! ;) I don't know much about Google code, but I know that the line breaking logic (or lack thereof) on Google Groups is a constant annoyance to me. But maybe I just haven't figured out how to use it yet. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Steve Holden wrote: Frankly I am getting a little tired of they way you are unable to even recognize that your readers may well have a sensible appreciation of the difficulties about which you write. As has been pointed out already, many readers here are extremely experienced programmers. You said in an earlier post that's not an insult, but that isn't really up to you to decide. If it gives offense then it probably is, whether it was intended to do so or not. You don't seem to appreciate the insulting nature of your tone, and calling people bozos is not likely to endear you to most c.l.py readers since it comes off as arrogant. You quoted what I wrote in reply to a personal attack against me, but you conveniently neglected to quote the original insult that I was replying to. OK, I'll concede that I shouldn't have replied to a personal insult with another insult, but why am I the only one at fault here rather than the guy who started it? Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior here, where outsiders like me are held to a higher standard than your insider friends. I don't know who you are, nor do I care what you and your little group think about me. As for DbC or what I call self-testing code, I have come to the (tentative) realization that it is easy to implement in current Python -- without resorting to the decorators hack. OK, maybe this should have been obvious to me from the start, but here goes: All you really need to test the pre-conditions of a function is a call at the top of the function to another function that checks the inputs. To test the post-conditions, you just need a call at the bottom of the function, just before the return, that checks the return values. Those functions can also check the invariants. Then you define a global variable to switch all the self-test functions on or off at once. An advantage of this approach is that all the self tests can be put at the bottom of the file (or perhaps in another file) to reduce clutter in the primary code. I'd still prefer PEP 316, but this seems like a reasonable alternative. One suggestion I have for PEP 316 is to provide a way to place the self-test checks in a separate file to reduce clutter. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Alex Martelli wrote: Russ specifically mentioned *mission-critical applications* as being outside of Python's possibilities; yet search IS mission critical to Google. Yes, reliability is obtained via a systems approach, Alex, I think you are missing the point. Yes, I'm sure that web searches are critical to Google's mission and commercial success. But the point is that a few subtle bugs cannot destroy Google. If your search engines and associated systems have bugs, you fix them (or simply tolerate them) and continue on. And if a user does not get the results he wants, he isn't likely to die over it -- or even care much. Online financial transactions are another matter altogether, of course. User won't die, but they will get very irate if they lose money. But I don't think that's what you are talking about here. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: Steve Holden wrote: Frankly I am getting a little tired of they way you are unable to even recognize that your readers may well have a sensible appreciation of the difficulties about which you write. As has been pointed out already, many readers here are extremely experienced programmers. You said in an earlier post that's not an insult, but that isn't really up to you to decide. If it gives offense then it probably is, whether it was intended to do so or not. You don't seem to appreciate the insulting nature of your tone, and calling people bozos is not likely to endear you to most c.l.py readers since it comes off as arrogant. You quoted what I wrote in reply to a personal attack against me, but you conveniently neglected to quote the original insult that I was replying to. OK, I'll concede that I shouldn't have replied to a personal insult with another insult, but why am I the only one at fault here rather than the guy who started it? You aren't, and if I wasn't being even-handed I apologize. Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior here, where outsiders like me are held to a higher standard than your insider friends. I don't know who you are, nor do I care what you and your little group think about me. Well that's a healthy attitude, but I am concerned that the Python community should be as welcoming as possible, so I don't like the fact that you feel you are being treated differently from anyone else. As for DbC or what I call self-testing code, I have come to the (tentative) realization that it is easy to implement in current Python -- without resorting to the decorators hack. OK, maybe this should have been obvious to me from the start, but here goes: All you really need to test the pre-conditions of a function is a call at the top of the function to another function that checks the inputs. To test the post-conditions, you just need a call at the bottom of the function, just before the return, that checks the return values. Those functions can also check the invariants. Then you define a global variable to switch all the self-test functions on or off at once. It does constrain functions to return only from the bottom of their code, though, which not all Python functions currently do. Though there's nothing to stop you putting the calls before every return. An advantage of this approach is that all the self tests can be put at the bottom of the file (or perhaps in another file) to reduce clutter in the primary code. I'd still prefer PEP 316, but this seems like a reasonable alternative. One suggestion I have for PEP 316 is to provide a way to place the self-test checks in a separate file to reduce clutter. That would be a sensible suggestion. It would also be possible to guard the lengthier tests with if debug to allow them to be omitted (presumably along with their imports with a little further effort in code organization) in (optimized) production mode where timings were critical. This could allow the benefits of DbC and unit testing at the same time. Putting the verification code into external functions does assume that global variables aren't used in the pre- and post-conditions, but I presume that's a part of the regime anyway. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Neil Cerutti wrote: Who watches the watchmen? The contracts are composed by the programmers writing the code. Is it likely that the same person who wrote a buggy function will know the right contract? The idea here is that errors in the self-testing code are unlikely to be correlated with errors in the primary code. Hence, you get a sort of multiplying effect on reliability. For example, if the chance of error in the primary code and the self-test code are each 0.01, the chance of an undetected error is approximately 0.01^2 or 0.0001. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Steve Holden wrote: Well that's a healthy attitude, but I am concerned that the Python community should be as welcoming as possible, so I don't like the fact that you feel you are being treated differently from anyone else. I certainly appreciate that. And I will try my best to refrain from the little personal zingers (and the big ones too). All you really need to test the pre-conditions of a function is a call at the top of the function to another function that checks the inputs. To test the post-conditions, you just need a call at the bottom of the function, just before the return, that checks the return values. Those functions can also check the invariants. Then you define a global variable to switch all the self-test functions on or off at once. It does constrain functions to return only from the bottom of their code, though, which not all Python functions currently do. Though there's nothing to stop you putting the calls before every return. Oops! I didn't think of that. The idea of putting one before every return certainly doesn't appeal to me. So much for that idea. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Neil Cerutti wrote: On 2007-08-31, Ricardo Aráoz [EMAIL PROTECTED] wrote: Russ wrote: Yes, thanks for reminding me about that. With SPARK Ada, it is possible for some real (non-trivial) applications to formally (i.e., mathematically) *prove* correctness by static analysis. I doubt that is possible without static declarative type- checking. SPARK Ada is for applications that really *must* be correct or people could die. I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? And the OS in which those programs operate, are they also formally proven correct? And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? Who watches the watchmen? The contracts are composed by the programmers writing the code. Is it likely that the same person who wrote a buggy function will know the right contract? Actually my point was that if a program is to be trusted in a critical situation (critical as in catastrophe if it goes wrong) then the OS, the compiler/interpreter etc should abide by the same rules. That is obviously not possible, so there's not much case in making the time investment necessary for correctness proof of a little program (or usually a little function inside a program) when the possibilities for failure are all around it and even in the code that will run that function. And we should resort to other more sensible answers to the safety problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: Alex, I think you are missing the point. Yes, I'm sure that web searches are critical to Google's mission and commercial success. But the point is that a few subtle bugs cannot destroy Google. If your search engines and associated systems have bugs, you fix them (or simply tolerate them) and continue on. And if a user does not get the results he wants, he isn't likely to die over it -- or even care much. But if this pattern of not getting wanted results is common, then the user will migrate to alternative search engines and this will *kill* the business. Wrong results won't impact ONE search, but many will impact the company business and will be part of the recipe to take it out of business. Online financial transactions are another matter altogether, of course. User won't die, but they will get very irate if they lose money. But I don't think that's what you are talking about here. Lets make someone loose his job and have all his money commitments compromised because of this money lost and we might be talking about people taking their lives. Again, this isn't 100% sure to happen, but it *can* happen. As it happens with a peacemaker: the user won't die if his heart skips one beat, but start skipping a series of them and you're incurring in serious problems. Just because the result isn't immediate it doesn't mean it isn't critical. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Ricardo Aráoz wrote: Actually my point was that if a program is to be trusted in a critical situation (critical as in catastrophe if it goes wrong) then the OS, the compiler/interpreter etc should abide by the same rules. That is obviously not possible, so there's not much case in making the time investment necessary for correctness proof of a little program (or usually a little function inside a program) when the possibilities for failure are all around it and even in the code that will run that function. And we should resort to other more sensible answers to the safety problem. I don't quite see it that way. I would agree that if your OS and compiler are unreliable, then it doesn't make much sense to bend over backwards worrying about the reliability of your application. But for real safety-critical applications, you have no excuse for not using a highly reliable OS and compiler. For really critical stuff, I think the real-time OSs are usually stripped down to the bare basics. And if you are using something like SPARK Ada, the language itself is stripped of many of the fancier features in Ada itself. (There's also something called the Ada Ravenscar profile, which I believe is geared for safety-critical use but is not quite as restrictive as SPARK.) Keep in mind that the OS and compiler are typically also used for many other applications, so they tend to get tested fairly thoroughly. And remember also that you won't have extraneous applications running -- like a web browser or a video game, so the OS will probably not be heavily stressed. The most likely source of failure is likely to be your application, so bending over backwards to get it right makes sense. Then again, if you are running C on Windows, you might as well just give up on reliability from the start. You don't have a prayer. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Jorge Godoy wrote: Russ wrote: Alex, I think you are missing the point. Yes, I'm sure that web searches are critical to Google's mission and commercial success. But the point is that a few subtle bugs cannot destroy Google. If your search engines and associated systems have bugs, you fix them (or simply tolerate them) and continue on. And if a user does not get the results he wants, he isn't likely to die over it -- or even care much. But if this pattern of not getting wanted results is common, then the user will migrate to alternative search engines and this will *kill* the business. Wrong results won't impact ONE search, but many will impact the company business and will be part of the recipe to take it out of business. Online financial transactions are another matter altogether, of course. User won't die, but they will get very irate if they lose money. But I don't think that's what you are talking about here. Lets make someone loose his job and have all his money commitments compromised because of this money lost and we might be talking about people taking their lives. Again, this isn't 100% sure to happen, but it *can* happen. As it happens with a peacemaker: the user won't die if his heart skips one beat, but start skipping a series of them and you're incurring in serious problems. Just because the result isn't immediate it doesn't mean it isn't critical. We probably need to distinguish between mission-critical, where a program has to work reliably for an organization to meet its goals, and safety-critical where people die or get hurt if the program misbehaves. The latter are the ones where you need to employ all possible techniques to avoid all possible failure modes. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 31, 6:45 pm, Steve Holden We probably need to distinguish between mission-critical, where a program has to work reliably for an organization to meet its goals, and safety-critical where people die or get hurt if the program misbehaves. The term mission critical itself can have a wide range of connotations. If a software failure would force a military pilot to abort his mission and hobble back home with a partially disabled aircraft, that's what I think of as mission critical software. If Google needs reliable software on its servers to maintain its revenue stream, that's another kind of mission critical software, but the criticality is certainly less immediate in that case. In the first case, the software glitch definitely causes mission failure. In the Google case, the software problems *may* ultimately cause mission failure, but probably only if nothing is done for quite some time to rectify the situation. If that is the case, then the software itself is not the critical factor unless it cannot be corrected and made to function properly in a reasonable amount of time. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
I disagree. IMO automatic testing is thousands of times better than design by contract and Python has already all the support you need (unittest, doctest, py.test, nose, ...) In theory, anything you can verify with design by contract you can also verify with unittest and the rest. However, design by contract has a major practical advantage: if you have real (or simulated) inputs available, you don't need to write a test driver or generate test inputs for each class or function. All you need to do is to run your program with the real (or simulated) inputs, all the internal data that gets passed around between classes and functions gets generated as usual, and everything gets tested automatically. In other words, you are spared the potentially considerable effort of generating and storing samples of all the internal data that gets passed around internally. You may want to do unit tests also, of course. Separate unit tests will give you more control and allow you to test individual classes and functions using a wider variety of inputs. But if your design by contract is comprehensive (i.e., passing it guarantees correct functioning of your code), then your unit tests can simply make use of the tests already available in the design by contract. So you've done no extra work in setting up the design by contract anyway. Another significant advantage of design by contract is that the tests are all right there in your source code, where they are much less likely to get lost or ignored by subsequent programmers who need to maintain the code. Relying on separate units tests is a bit like relying on extended comments or design documents that are separate from the code. Yes, those are certainly useful, but they do not eliminate the need for comments in the code. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 8/29/07, Russ [EMAIL PROTECTED] wrote: But it's always a good idea to make your software correct and as reliable as possible, isn't it? The problem is the external constraints on the project. As the old saying goes: Cheap, fast, reliable: choose any two. If you are suggesting that programming by contract is not appropriate for every application, you will get no argument from me. All I am suggesting is that having the option to use it when you need it is very desirable, and it can possibly enhance the versatility of Python by making Python more suitable for *some* mission-critical applications. PEP 316 introduces new syntax for a limited use feature. That's pretty much a no-starter, in my opinion, and past experience tends to bear that out. Furthermore, it predates decorators and context managers, which give all the syntax support you need and let you move the actual DBC features into a library. I can't remember if I mentioned this before but I believe that Philip Ebys PEAK toolkit has some stuff you could use for DBC. I once read a book on something called SPARK Ada, which also supports programming by contract. I was pleasantly surprised to discover yesterday that support for the such methods is also available for Python. However, the support would obviously be a bit stronger if it were in the core Python distribution. If a well written contract library were to exist, and people were to use it, and the author were interested, it would make a decent candidate for inclusion in the standard library, and I wouldn't oppose such a thing (for all my opinion is worth, ie essentially nothing). The PEP 316 special syntax is another matter entirely. The best way for this to happen is for you to find or write such a library, and use it to write good code. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
PEP 316 introduces new syntax for a limited use feature. That's pretty much a no-starter, in my opinion, and past experience tends to bear that out. Furthermore, it predates decorators and context managers, which give all the syntax support you need and let you move the actual DBC features into a library. I can't remember if I mentioned this before but I believe that Philip Ebys PEAK toolkit has some stuff you could use for DBC. I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. And if I am not mistaken, the new syntax would appear only in doc strings, not in the regular Python code itself. We're not really talking here about changing the core Python syntax itself, so I don't see it as a non-starter. Anyone who chooses not to use would be completely unaffected. As far as I can tell, Terence Way has done a nice job of implementing design by contract for Python, but perhaps a better approach is possible. The advantage of making part of the core Python distribution is that it would get vetted more thoroughly. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 8/30/07, Russ [EMAIL PROTECTED] wrote: PEP 316 introduces new syntax for a limited use feature. That's pretty much a no-starter, in my opinion, and past experience tends to bear that out. Furthermore, it predates decorators and context managers, which give all the syntax support you need and let you move the actual DBC features into a library. I can't remember if I mentioned this before but I believe that Philip Ebys PEAK toolkit has some stuff you could use for DBC. I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. And if I am not mistaken, the new syntax would appear only in doc strings, not in the regular Python code itself. We're not really talking here about changing the core Python syntax itself, so I don't see it as a non-starter. Anyone who chooses not to use would be completely unaffected. I misread the pep as adding the identifiers into the actual python syntax, not in the docstring. All the more reason to implement it as a library, then. I actually think that decorators and context managers would be nicer than special docstring syntax, but I recognize the benefit of the doctest style approach. As far as I can tell, Terence Way has done a nice job of implementing design by contract for Python, but perhaps a better approach is possible. The advantage of making part of the core Python distribution is that it would get vetted more thoroughly. Things get vetted *before* they get added to the core, not after. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Things get vetted *before* they get added to the core, not after. I realize that. I meant that it would get vetted in the process of putting it into the core. That would provide more confidence that it was done the best possible way -- or close to it. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : (snip) I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. class Parrot(object): @pre(lambda x : x != 42) @post(lambda result: result != 42) @invariant(lambda self: self.x == 42) def reliable_method(self, x): # your code here return something -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. I get the strong impression you don't really understand how condescending you are. I have not yet personally used it, You have no working experience with the concept, but you think it should make it into Python's core ??? -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Bruno Desthuilliers wrote: Russ a écrit : (snip) I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. class Parrot(object): @pre(lambda x : x != 42) @post(lambda result: result != 42) @invariant(lambda self: self.x == 42) def reliable_method(self, x): # your code here return something That looks like new syntax to me. Did I miss your point? I have no strong leaning about what the exact syntax should be for programming by contract. The syntax you show above seems reasonable, except that I am not sure about requiring that everything be put inside parentheses. That seems a bit confining for more complex conditions. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 8/30/07, Russ [EMAIL PROTECTED] wrote: Bruno Desthuilliers wrote: Russ a écrit : (snip) I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. class Parrot(object): @pre(lambda x : x != 42) @post(lambda result: result != 42) @invariant(lambda self: self.x == 42) def reliable_method(self, x): # your code here return something That looks like new syntax to me. Did I miss your point? I have no strong leaning about what the exact syntax should be for programming by contract. The syntax you show above seems reasonable, except that I am not sure about requiring that everything be put inside parentheses. That seems a bit confining for more complex conditions. This is existing, working python syntax (although the decorators would need to be defined). -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Bruno Desthuilliers wrote: Russ a écrit : On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. I get the strong impression you don't really understand how condescending you are. When someone writes something as ignorant as that, they need to be called on it. So you can implement everything you need already in Python? Yes, of course, and you can do it in machine language too -- if you have the time to waste. I have not yet personally used it, You have no working experience with the concept, but you think it should make it into Python's core ??? I don't need to use it to understand the concept. That has been explained brilliantly by the Eiffel and SPARK Ada folks. I am also smart enough to figure out that it can greatly enhance unit testing, and it can also be used as an integral part of unit testing. Once you have the conditions in place, all you need to do in your unit tests is to send inputs to the unit and wait to see if exceptions are thrown. In fact, I would even propose a new name for programming by contract. I would call it self-testing code because the code essentially tests itself every time it is run with the checks activated. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : Bruno Desthuilliers wrote: Russ a écrit : (snip) I don't see how you can avoid adding some new syntax, given that Python does not currently have syntax for specifying invariants and pre- and post- conditions. class Parrot(object): @pre(lambda x : x != 42) @post(lambda result: result != 42) @invariant(lambda self: self.x == 42) def reliable_method(self, x): # your code here return something That looks like new syntax to me. It's the syntax for decorator functions, and it's not that new - it cames with Python 2.4, released November 30, 2004. Did I miss your point? Yes. -- http://mail.python.org/mailman/listinfo/python-list
RE: status of Programming by Contract (PEP 316)?
On Behalf Of Russ Once you have the conditions in place, all you need to do in your unit tests is to send inputs to the unit and wait to see if exceptions are thrown. That sounds a little ambitious to me... However, you may want to look at the typecheck module (you can get it via easy_install). I think you could probably extend it to do DBC. http://oakwinter.com/code/typecheck/ from typecheck import accepts, returns, Any @accepts(str, int, Any()) @returns(list) def makelist(a, b, c): return [a, b, c] makelist(spam, 42, object()) ['spam', 42, object object at 0x00AE0470] makelist(42, spam, 3.4) Traceback (most recent call last): File pyshell#25, line 1, in module makelist(42, spam, 3.4) File C:\Python25\lib\site-packages\typecheck-0.3.5-py2.5.egg\typecheck\__init__. py, line 1340, in fake_function File C:\Python25\lib\site-packages\typecheck-0.3.5-py2.5.egg\typecheck\__init__. py, line 1419, in __check_args TypeCheckError: Argument a: for 42, expected type 'str', got type 'int' I tried using DBC for a time in C++ (using a library with a clever assembly-language hack). I personally found it neater having such code in unit tests, but obviously, it's a matter of preference. Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
That looks like new syntax to me. It's the syntax for decorator functions, and it's not that new - it cames with Python 2.4, released November 30, 2004. After looking more carefully at your example, I don't think it is as clean and logical as the PEP 316 syntax. At first I thought that your pre and post-conditions applied to the class, but now I realize that they apply to the function. I prefer to see the conditions inside the function in the doc string. That just seems more logical to me. With all due respect, your proposal is interesting, but I think it overextends the function decorator idea a bit. A nit-pick I might have with the PEP 316 syntax is that I think invariant should be spelled out rather than abbreviated as inv. The same might apply to pre- condition and post-condition. But that's obviously no big deal. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : Bruno Desthuilliers wrote: Russ a écrit : On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. I get the strong impression you don't really understand how condescending you are. When someone writes something as ignorant as that, they need to be called on it. When someone writes something as arrogant as that, they need to be called on it. Michele obviously knows what DbC is (probably better than you do), and he also knows Python enough to know why you don't need to add anything to Python to have it. So you can implement everything you need already in Python? Talking about DbC ? Yes, of course, Yes, of course. A couple of decorator functions and you're done. It's pretty trivial, and that's why Michele told you could implement it by yourself. (snip) I have not yet personally used it, You have no working experience with the concept, but you think it should make it into Python's core ??? I don't need to use it to understand the concept. That has been explained brilliantly by the Eiffel and SPARK Ada folks. FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. One needs to have working experience with a concept to know what it's really worth. Too bad for you, you're too smart to understand this. I am also smart enough Yes, obviously really smart. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ a écrit : That looks like new syntax to me. It's the syntax for decorator functions, and it's not that new - it cames with Python 2.4, released November 30, 2004. After looking more carefully at your example, I don't think it is as clean and logical as the PEP 316 syntax. Possibly not, but at least it's trivial to implement. At first I thought that your pre and post-conditions applied to the class, Pre and post conditions applying to the class ? Now that's an interesting concept. IIRC, Eiffels pre and post conditions only apply to methods, and I fail to see how they could apply to a class. But since you're an expert on the subject, I don't doubt you'll enlighten us ? but now I realize that they apply to the function. I prefer to see the conditions inside the function in the doc string. That just seems more logical to me. Not to me. Doc strings are not for implementation. But if you want to implement a DbC module using doc strings, please do so. With all due respect, your proposal is interesting, but I think it overextends the function decorator idea a bit. Definitively not, on the contrary - that's *exactly* what decorators are for. Else, they would be nothing more than HOFs, and there would be no point in having this syntactic sugar. (snip). -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Ryan Ginstrom wrote: I tried using DBC for a time in C++ (using a library with a clever assembly-language hack). I personally found it neater having such code in unit tests, but obviously, it's a matter of preference. I agree that it ultimately boils down to preference, but as I tried to explain earlier, I don't think that unit tests are equivalent to DBC (or, as I referred to it earlier, self-testing code). Unit tests are not automatically executed when you run your application. You need to write the drivers and generate sample inputs to all the functions in your application, which can be very time-consuming. And if you think you can anticipate all the weird internal data that might come up in the execution of your application, then either your application is very simple or you are fooling yourself. With self-testing code, on the other hand, all you need to do is to get sample inputs to your application (not internal inputs to functions) and run the entire application. That is much simpler and more comprehensive than unit testing. Again, I recognize that it doesn't necessarily replace unit testing completely. For one thing, unit testing can test for specific outputs for specific inputs, whereas you wouldn't want to clutter your actual code with such specific cases. For example, a unit test for a sorting function could provide a specific input and test for a specific output, but you probably wouldn't want to clutter your code with such a case. The self-tests in your code would be more for general tests. PEP 316 provides an excellent of comprehensive tests for a sorting function. If you pass those tests, you can be sure your function worked correctly. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Pre and post conditions applying to the class ? Now that's an interesting concept. IIRC, Eiffels pre and post conditions only apply to methods, and I fail to see how they could apply to a class. But since you're an expert on the subject, I don't doubt you'll enlighten us ? I made a simple mistake. Excuse me. Oh wait ... aren't you one of the sensitivity police who laid into me for criticizing someone else. For the record, the guy I criticized made ridiculous assertions about DBC. All I did was to make a simple mistake about an inconsequential matter. No, pre and post conditions obviously don't apply to classes, but all I said was that that's how it appeared to me at first glance. If you are upset about my criticism of one of your colleagues, please tell him to quite making outrageous assertions about something he obviously knows little about. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. And they are probably right. I don't think you understand what they mean by reliable programs. Any idea how much Python is used for flight control systems in commercial transport aircraft or jet fighters? How about ballistic missile launch and guidance systems? Any idea why? For the record, I think that DBS could possibly make Python more suitable for *some* mission-critical or perhaps even safety-critical applications, but it will never be able to compete with SPARK Ada or even Ada at the highest level of that domain. The important question is this: why do I waste my time with bozos like you? -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Bruno Desthuilliers [EMAIL PROTECTED] writes: FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. I don't know about Eiffel but at least an important subset of SPARK Ada's DBC stuff is done using static analysis tools (not actually built into the compiler as it happens) to verify statically (i.e. without actually running the code) that the code fulfills the DBC conditions. I don't see any way to do that with Python decorators. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Paul Rubin wrote: Bruno Desthuilliers [EMAIL PROTECTED] writes: FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. I don't know about Eiffel but at least an important subset of SPARK Ada's DBC stuff is done using static analysis tools (not actually built into the compiler as it happens) to verify statically (i.e. without actually running the code) that the code fulfills the DBC conditions. I don't see any way to do that with Python decorators. Yes, thanks for reminding me about that. With SPARK Ada, it is possible for some real (non-trivial) applications to formally (i.e., mathematically) *prove* correctness by static analysis. I doubt that is possible without static declarative type- checking. SPARK Ada is for applications that really *must* be correct or people could die. With all due respect, most (not all, but most) Python programmers never get near such programs and have no idea about how stringent the requirements are. Nor do most programmers in general, for that matter. (It's not an insult) -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ [EMAIL PROTECTED] wrote: ... programs. Any idea how much Python is used for flight control systems in commercial transport aircraft or jet fighters? Are there differences in reliability requirements between the parts of such control systems that run on aircraft themselves, and those that run in airports' control towers? Because Python *IS* used in the latter case, cfr http://www.python.org/about/success/frequentis/ ... if on-plane control SW requires hard-real-time response, that might be a more credible reason why Python would be inappropriate (any garbage collected language is NOT a candidate for hard-real-time SW!) than your implied aspersions against Python's reliability. According to http://uptime.pingdom.com/site/month_summary/site_name/www.google.com, Google's current uptime is around 99.99%, with many months at 100% and a few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW, and in real-world conditions where power can go away, network cables can accidentally get cut, etc. I'm Uber Tech Lead for Production Systems at Google -- i.e., the groups I uber-lead are responsible for some software which (partly by automating things as much as possible) empowers our wondrous Site Reliability Engineers and network specialists to achieve that uptime in face of all the Bad Stuff the world can and does throw at us. Guess what programming language I'm a well-known expert of...? The important question is this: why do I waste my time with bozos like you? Yeah, good question indeed, and I'm asking myself that -- somebody who posts to this group in order to attack the reliability of the language the group is about (and appears to be supremely ignorant about its use in air-traffic control and for high-reliability mission-critical applications such as Google's Production Systems software) might well be considered not worth responding to. OTOH, you _did_ irritate me enough that I feel happier for venting in response;-) Oh, FYI -- among the many tasks I undertook in my quarter-century long career was leading and coordinating pilot projects in Eiffel for one employer, many years ago. The result of the pilot was that Eiffel and its DbC features didn't really let us save any of the extensive testing we performed for C++-coded components, and the overall reliability of such extensively tested components was not different in a statistically significant way whether they were coded in C++ or Eiffel; Eiffel did let us catch a few bugs marginally earlier (but then, I'm now convinced that, at that distant time, we used by far too few unit-tests for early bug catching and relied too much on regression and acceptance tests), but that definitely was _not_ enough to pay for itself. DbC and allegedly rigorous compile-time typechecking (regularly too weak due to Eiffel's covariant vs countervariant approach, btw...), based on those empirical results, appear to be way overhyped. A small decorator library supporting DbC would probably be a nice addition to Python, but it should first prove itself in the field by being released and supported as an add-on and gaining wide acceptance: arguments such as yours are definitely NOT going to change that. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: Paul Rubin wrote: Bruno Desthuilliers [EMAIL PROTECTED] writes: FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. I don't know about Eiffel but at least an important subset of SPARK Ada's DBC stuff is done using static analysis tools (not actually built into the compiler as it happens) to verify statically (i.e. without actually running the code) that the code fulfills the DBC conditions. I don't see any way to do that with Python decorators. Yes, thanks for reminding me about that. With SPARK Ada, it is possible for some real (non-trivial) applications to formally (i.e., mathematically) *prove* correctness by static analysis. I doubt that is possible without static declarative type- checking. SPARK Ada is for applications that really *must* be correct or people could die. I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? And the OS in which those programs operate, are they also formally proven correct? And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? With all due respect, most (not all, but most) Python programmers never get near such programs and have no idea about how stringent the requirements are. Nor do most programmers in general, for that matter. (It's not an insult) -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 30, 10:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote: Russ [EMAIL PROTECTED] wrote: ... programs. Any idea how much Python is used for flight control systems in commercial transport aircraft or jet fighters? Are there differences in reliability requirements between the parts of such control systems that run on aircraft themselves, and those that run in airports' control towers? Yes. Because Python *IS* used in the latter case, cfr http://www.python.org/about/success/frequentis/ ... if on-plane control SW requires hard-real-time response, Yes. that might be a more credible reason why Python would be inappropriate (any garbage collected language is NOT a candidate for hard-real-time SW!) than your implied aspersions against Python's reliability. Not really relevant, since there is no (or very little) dynamic memory allocation. Python really isn't suitable for in-flight controls for various reasons, and mission critical concerns is a minor one (systems with less underlying complexity tend to have fewer failure modes). But mostly it's raw throughput: Python is just too slow. Flight control computers have to be powerful enough make a ton of mathematical calculations in a matter of milliseconds, and under strict weight and power constraints. The cost of running 100 times slower than optimal is just too high. At my current project, we're struggling with throughput even though we use highly optimized code. Python would be completely out of the question. Now, control towers don't have these constraints, and system failure is not nearly as critical, so Python is a better option there. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 30, 9:41 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: Bruno Desthuilliers [EMAIL PROTECTED] writes: FWIW, the Eiffel and SPARK Ada folks also brilliantly explained why one can not hope to write reliable programs without strict static declarative type-checking. I don't know about Eiffel but at least an important subset of SPARK Ada's DBC stuff is done using static analysis tools (not actually built into the compiler as it happens) to verify statically (i.e. without actually running the code) that the code fulfills the DBC conditions. I don't see any way to do that with Python decorators. I don't see any way to do that in Python with built-in DBC syntax, either. :) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
[EMAIL PROTECTED] (Alex Martelli) writes: DbC and allegedly rigorous compile-time typechecking (regularly too weak due to Eiffel's covariant vs countervariant approach, btw...), based on those empirical results, appear to be way overhyped. My experience with writing Eiffel code was a bit different. Integrating code from multiple sources happened much faster than I expected, and the code ran reliably. There were a couple of instances where previously uncombined code was linked together and worked on the first run. Perhaps more important, however, is that method contracts provide important documentation about how each method is supposed to work -- what it assumes and what must be true when it returns. Using Eiffel changed my coding process. Often I'd write the pre- and postconditions first, then write the method body, just as programmers today often write unit tests first. Thinking carefully about the contracts and writing them down, so they could be verified, makes the code more reliable and maintainable. The contracts are part of the source code, not a fuzzy concept in each programmer's head. The contracts are also useful when discussing the code with domain experts who are not programmers. They can read and understand the flat short view of a class, which includes all the method names, method comments, and contracts, but leaves out the method implementations. Here's an example, Eiffel's String class: http://www.nenie.org/eiffel/flatshort/string.html In any case, I'm still not sure whether it would be useful to integrate DbC into Python. A library that implements DbC for Common Lisp has not gotten much traction in that community, which has a similar style of software development. Perhaps it's just too much to ask that programmers write both unit tests and method contracts. bob -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Robert Brown [EMAIL PROTECTED] writes: In any case, I'm still not sure whether it would be useful to integrate DbC into Python. I guess I'm a little confused about what it would mean. Suppose you want to write a function that looks for a value using binary search in a sorted list, n = bsearch(a,x). The contract is: precondition: the input list a is sorted. postcondition: the output is an integer n, such that if x is an element of the list, then a[n] == x. If x is not in the list, then n is -1. This is a reasonable application of dbc since the precondition and postcondition are easy to specify and check, but the binary search algorithm is tricky enough to be susceptible to implementation errors. The trouble is, the obvious way to write the precondition and postcondition take linear time, while the binary search should take log(n) time. In the traditional unit test approach, that's ok, you'd run the test as part of the build process but not each time the function is actually called. With something like SPARK/Ada (and maybe Eiffel), you'd statically validate the conditions. But in Python, the check occurs at runtime unless you disable it, famously compared to wearing your parachute on the ground but taking it off once your plane is in the air. I guess one difference from unit test philosophy is that at least sometime, you'd run the entire application with all the dbc checks enabled, and just live with the slowdown. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Carl Banks [EMAIL PROTECTED] wrote: Python really isn't suitable for in-flight controls for various reasons, and mission critical concerns is a minor one (systems with less underlying complexity tend to have fewer failure modes). But mostly it's raw throughput: Python is just too slow. Flight control computers have to be powerful enough make a ton of mathematical calculations in a matter of milliseconds, and under strict weight and power constraints. The cost of running 100 times slower than optimal is just too high. I'm not convinced that's true for all avionics uses. Certainly, if you're doing the fly-by-wire stability control system for a dynamically unstable airframe, you need a lot of compute power and guaranteed real-time response (recovery from a VMC rollover is no time for garbage collection). But, not everything in an airplane is like that. Take something relatively complicated like a GPS. The basic receiver is pretty compute intensive, but that's likely to be a dedicated chip. Most of the functionality in the box, however, requires a lot less horsepower. You need to handle user input (i.e. keep up a scan on maybe 20 keys), and update a low-res display (320 x 240 x 8 bit color is typical) with text or cartoon graphics. There are certain real-time calculations which need to be done, such as time, distance, and bearing to the next waypoint, but these are typically updated a few times a second. Like most things that use Python (or TCL, or Ruby, or ...), I would expect that most of the low-level stuff would be done in something like C and Python would be used for the glue code and things where there's no time pressure. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
I've always wondered... Are the compilers (or interpreters), which take these programs to machine code, also formally proven correct? No, they are not formally proven correct (too complicated for that), but I believe they are certified to a higher level than your typical compiler. I think that Ada compilers used for certain safety-critical applications must meet higher standards than, say, GNU Ada, for example. And the OS in which those programs operate, are they also formally proven correct? Same as above, if I am not mistaken. And the hardware, microprocessor, electric supply, etc. are they also 'proven correct'? I think the microprocessors used for flight control, for example, are certified to a higher level than standard microprocessors. How would you prove a power supply to be correct? I'm sure they meet higher reliability standards too. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 31, 3:18 am, Russ [EMAIL PROTECTED] wrote: For the record, the guy I criticized made ridiculous assertions about DBC. And that would be me? Oh my! LOL! This is not nearly as fun as the guy who explained to Steve Holden how Python works, but still ... ;) If you are upset about my criticism of one of your colleagues, please tell him to quite making outrageous assertions about something he obviously knows little about. For the record I read the design by contract book by Meyer years ago (the first edition) and I could not stomach it. The paper you mentioned is even worse. Programmers asserting that a given metodology can give 100% reliable software are incompetents or liars or both. Period. Of course there are methodologies which are better than others (for instance automatic tests are better than manual tests) and one should try various approaches on the field. However, IMNSHO, nowadays design by contract has been superseded by unit tests and it makes little sense to use it. Once you have automatic tests and once you make liberal use of assert statements in your code, you should not feel the need for more than that. You may think differently of course, but you should know that I am a ferocious opponent of heavyweight approaches, huge frameworks, and all that. Most people in the Python community are. This is why I think dBC will never enter in the core, and it would be extremely little used even as a third party library (BTW, it has already happened). Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
I guess one difference from unit test philosophy is that at least sometime, you'd run the entire application with all the dbc checks enabled, and just live with the slowdown. Yes, that's right. You don't expect to run efficiently with the self- test checks activated, but you can test your code more conveniently and comprehensively than unit tests by simply running your program as usual -- except with the checks activated. If you do that for any significant period of time, many bugs will find themselves, I'm sure. Also, to repeat once again, the embedded self-test (DbC) checks can be used for unit testing too. You simply activate the self-tests when you do your unit testing, and wait for them to throw exceptions. So it seems to me that you've killed two birds with one stone. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 29, 7:21 am, Russ [EMAIL PROTECTED] wrote: Thanks for that information. That's too bad, because it seems like a strong positive capability to add to Python. I wonder why the cold reception. Were there problems with the idea itself or just the implementation? Or is it just a low priority? Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. In any case, I guess it is still perfectly usable even if it isn't part of the core Python. Has anyone used it? If so, how well did it work? Thanks. Dunno, I would be curious myself to know if there are users of these frameworks (including AOP frameworks in Python) or if they are just exercises. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. I have not yet personally used it, but I am interested in anything that can help to make my programs more reliable. If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software to be correct and reliable as possible, I think you you should be interested in it. You might want to read this: http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 29, 8:45 am, Russ [EMAIL PROTECTED] wrote: I get the strong impression you don't really understand what programming by contract is. I have not yet personally used it, but I am interested in anything that can help to make my programs more reliable. If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software to be correct and reliable as possible, I think you you should be interested in it. You might want to read this: http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page... That paper contains only a good think: a link to the contrarian view http://home.flash.net/~kennieg/ariane.html#s3.1.5 -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
In article [EMAIL PROTECTED], Russ [EMAIL PROTECTED] wrote: I just stumbled onto PEP 316: Programming by Contract for Python (http://www.python.org/dev/peps/pep-0316/). This would be a great addition to Python, but I see that it was submitted way back in 2003, and its status is deferred. I did a quick search on comp.lang.python, but I don't seem to see much on it. Does anyone know what the real status is of getting this into standard Python? Thanks. The way to get this into Python is to get people to use it as a stand-alone module. It's already in PyPI, so now it's time for some marketing. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On 8/29/07, Russ [EMAIL PROTECTED] wrote: On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. Don't be condescending. I have not yet personally used it, but I am interested in anything that can help to make my programs more reliable. The entire issue of software reliability, exactly what metrics you should use to measure it, and whether any specific technique results in more of it are very much in debate. If you want to experiment with these techniques, you can do so without them being in the Python core. Python has all the support you need to play with them right now. If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software to be correct and reliable as possible, I think you you should be interested in it. You might want to read this: You don't want your software to KILL BABIES, do you? If you don't want your programs to KILL BABIES then you should use our technique, so you don't KILL BABIES. There are ways to make correct programs besides DBC. It may not even help in the general case - just as with unit testing and type proving, you're going to be limited by what you don't think to assert or document or test, and I've seen no evidence that DBC is any better than anything else at preventing unwritten assumptions. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Chris Mellon wrote: On 8/29/07, Russ [EMAIL PROTECTED] wrote: [...] If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software to be correct and reliable as possible, I think you you should be interested in it. You might want to read this: You don't want your software to KILL BABIES, do you? If you don't want your programs to KILL BABIES then you should use our technique, so you don't KILL BABIES. There are ways to make correct programs besides DBC. It may not even help in the general case - just as with unit testing and type proving, you're going to be limited by what you don't think to assert or document or test, and I've seen no evidence that DBC is any better than anything else at preventing unwritten assumptions. Personally I have found the best strategy to be KWYD: know what you're doing. Your assertion that success of DBC relies on the competence of the practitioner is indeed true, just as it is for all other methodologies. The number of programmers who *don't* know what they are doing and yet manage to find well-paid employment in mission-critical system implementation is truly staggering. If I can blow my own trumpet briefly, two customers (each using over 25 kLOC I have delivered over the years) ran for two years while I was away in the UK without having to make a single support call. One of the systems was actually locked in a cupboard all that time (though I have since advised that client to at least apply OS patches to bring it up to date). This was achieved by defensive programming, understanding the user requirements and just generally knowing what I was doing. Nevertheless I would hesitate to write code for such demanding areas as real-time rocket flight control, because I just don't think I'm that good. Very few people are, and learning as you go can be disastrously expensive when military and space projects are involved. But it's always a good idea to make your software correct and as reliable as possible, isn't it? The problem is the external constraints on the project. As the old saying goes: Cheap, fast, reliable: choose any two. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Tue, 28 Aug 2007 23:45:28 -0700, Russ wrote: On Aug 28, 10:58 pm, Michele Simionato [EMAIL PROTECTED] wrote: Why do you think that would ad a strong positive capability? To me at least it seems a big fat lot of over-engineering, not needed in 99% of programs. In the remaining 1%, it would still not be needed since Python provides out of the box very powerful metaprogramming capabilities so that you can implement yourself the checks you need, if you really need them. I get the strong impression you don't really understand what programming by contract is. I have not yet personally used it, but I am interested in anything that can help to make my programs more reliable. If you are programming something that doesn't really need to be correct, than you probably don't need it. But if you really need (or want) your software to be correct and reliable as possible, I think you you should be interested in it. You might want to read this: http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html I agree with Chris - there's no need to be condescending. However, I agree with you that this is a valuable addition to a language. It's not that Eiffel, by having preconditions and postconditions, is doing anything that cannot be done in python already. It's more that by making these things a formal part of the language, or at least a module that facilitates them, one gives a sort of stamp of approval to adding a ton of assertions about how your code is supposed to work /when/working/in/that/language, which makes debugging a relative snap. Isn't that something people should want for python? Sturdy code and easy debugging? I've been trying to write my python code with tons of unnecessary if statements that check out my assumptions, and I'm finding more or less what the Eiffel people claim: I'm investing a little bit of upfront time, and getting a huge payoff in the backend as my code starts to debug itself. But I likely never would've started taking my error checking to such extremes if I hadn't been curious about Eiffel for a while. Throwing in tons of error and assumption checking mostly eliminates silly tracing from procedure to function to procedure to function, trying to find the ultimate root cause of a problem. Usually, the root cause is identified in an error on stderr or similar. Keep in mind that debugging usually takes far longer than the initial coding. Programming by contract seems to balance that out, relatively speaking. Granted, we could just say You should check for these things anyway, or You should know what you're doing, but... Isn't that kind of what assembler programmers used to say to Lisp, FORTRAN and COBOL programmers? And what about the case where you've written a piece of code, and someone else has written another, and the two pieces of code need to interact? Odds are pretty good that if this code has much substance, there'll be opportunity for subtly different assumptions about what should be happening in each (yes, well abstracted code will be misassumption-resistant, but even the best OOP programmers will run afoul of this /sometimes/). Perhaps both these programmers Know what they're doing, but they don't necessarily know what the other is doing! IMO, putting Programming by Contract into python as part of the language itself, or as a simple module, is a little bit like a company or department coming up with a mission statement. It's easy to say that it's meaningless, and some will ignore it, but it still kind of sets the tone for how things should be done. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
But it's always a good idea to make your software correct and as reliable as possible, isn't it? The problem is the external constraints on the project. As the old saying goes: Cheap, fast, reliable: choose any two. If you are suggesting that programming by contract is not appropriate for every application, you will get no argument from me. All I am suggesting is that having the option to use it when you need it is very desirable, and it can possibly enhance the versatility of Python by making Python more suitable for *some* mission-critical applications. I once read a book on something called SPARK Ada, which also supports programming by contract. I was pleasantly surprised to discover yesterday that support for the such methods is also available for Python. However, the support would obviously be a bit stronger if it were in the core Python distribution. What I really like about the implementation I cited above is that the invariants and the pre and post-conditions can all be put right in the doc string at the beginning of each class or function. You can think of it as a detailed specification of the intent (or of some of the requirements or constraints) of the class or function -- which can be *automatically* checked during testing. It can also be used for explicit type checking. It's like having some of your most critical unit tests built right into your code. It may make your code very verbose, but it will also be very complete. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 30, 1:17 am, Dan Stromberg - Datallegro [EMAIL PROTECTED] wrote: IMO, putting Programming by Contract into python as part of the language itself, or as a simple module, is a little bit like a company or department coming up with a mission statement. It's easy to say that it's meaningless, and some will ignore it, but it still kind of sets the tone for how things should be done. I disagree. IMO automatic testing is thousands of times better than design by contract and Python has already all the support you need (unittest, doctest, py.test, nose, ...) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
status of Programming by Contract (PEP 316)?
I just stumbled onto PEP 316: Programming by Contract for Python (http://www.python.org/dev/peps/pep-0316/). This would be a great addition to Python, but I see that it was submitted way back in 2003, and its status is deferred. I did a quick search on comp.lang.python, but I don't seem to see much on it. Does anyone know what the real status is of getting this into standard Python? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
Russ wrote: I just stumbled onto PEP 316: Programming by Contract for Python (http://www.python.org/dev/peps/pep-0316/). This would be a great addition to Python, but I see that it was submitted way back in 2003, and its status is deferred. I did a quick search on comp.lang.python, but I don't seem to see much on it. Does anyone know what the real status is of getting this into standard Python? Thanks. PEP's with deferred status typically aren't going into Python any time soon, if ever. Since the due date for all Python 3 core changes is long past due, you won't even be seeing it in Python 3. Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: status of Programming by Contract (PEP 316)?
On Aug 28, 9:35 pm, Steven Bethard [EMAIL PROTECTED] wrote: Russ wrote: I just stumbled onto PEP 316: Programming by Contract for Python (http://www.python.org/dev/peps/pep-0316/). This would be a great addition to Python, but I see that it was submitted way back in 2003, and its status is deferred. I did a quick search on comp.lang.python, but I don't seem to see much on it. Does anyone know what the real status is of getting this into standard Python? Thanks. PEP's with deferred status typically aren't going into Python any time soon, if ever. Since the due date for all Python 3 core changes is long past due, you won't even be seeing it in Python 3. Steve Thanks for that information. That's too bad, because it seems like a strong positive capability to add to Python. I wonder why the cold reception. Were there problems with the idea itself or just the implementation? Or is it just a low priority? In any case, I guess it is still perfectly usable even if it isn't part of the core Python. Has anyone used it? If so, how well did it work? Thanks. -- http://mail.python.org/mailman/listinfo/python-list