Project organization and import
jgodoy at gmail.com
Tue Mar 6 23:51:33 CET 2007
aleax at mac.com (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 <jgodoy at gmail.com>
More information about the Python-list