[EMAIL PROTECTED] (Alex Martelli) writes: > Not sure I get what you mean; when I write tests, just as when I write > production code, I'm focused (not worried:-) about the application
semantics... ;-) Thanks for the correction. > functionality I'm supposed to deliver. The language mostly "gets out of > my way" -- that's why I like Python, after all:-). That's the same reason why I like it. I believe it is not a coincidence that we both like writing Python code. But there are cases where investigating is more necessary than testing. This is where I see the need of the interactive session. For program's features I also write tests. > I do generally keep an interactive interpreter running in its own > window, and help and dir are probably the functions I call most often > there. If I need to microbenchmark for speed, I use timeit (which I > find far handier to use from the commandline). I wouldn't frame this as > "worried with how to best use the language" though; it's more akin to a > handy reference manual (I also keep a copy of the Nutshell handy for > exactly the same reason -- some things are best looked up on paper). That's the same use -- and the same most used functions -- that I have here. I believe that I wasn't clear on my previous post, and this is why you saw a different meaning to it. > I don't really see "getting a bit big to setup" as the motivation for > writing automated, repeatable tests (including load-tests, if speed is > such a hot topic in your case); rather, the key issue is, will you ever It's not for writing tests. It's for investigating things. If I have to open database connections, make several queries to get to a point where I have the object that I want to "dir()", it is easier to me to put that all in a file. It isn't a test. > want to run this again? For example, say you want to check the relative > speeds of approaches A and B -- if you do that in a way that's not > automated and repeatable (i.e., not by writing scripts), then you'll > have to repeat those manual operations exactly every time you refactor > your code, upgrade Python or your OS or some library, switch to another > system (HW or SW), etc, etc. Even if it's only three or four steps, who > needs the aggravation? Almost anything worth doing (in the realm of > testing, measuring and variously characterizing software, at least) is > worth automating, to avoid any need for repeated manual labor; that's > how you get real productivity, by doing ever less work yourself and > pushing ever more work down to your computer. I won't write a script to write two commands and rerun them often. But I would for some more -- lets say starting from 5 commands I might start thinking about having this somewhere where I can at least Cut'n'Past to the interactive interpreter (even with readline's help). -- Jorge Godoy <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
