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
