Re: Project organization and import
- From: Jorge Godoy <jgodoy@xxxxxxxxx>
- Date: Tue, 06 Mar 2007 19:51:33 -0300
aleax@xxxxxxx (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@xxxxxxxxx>
.
- References:
- Project organization and import
- From: Martin Unsal
- Re: Project organization and import
- From: Jorge Godoy
- Re: Project organization and import
- From: Martin Unsal
- Re: Project organization and import
- From: Bruno Desthuilliers
- Re: Project organization and import
- From: Alex Martelli
- Re: Project organization and import
- From: Jorge Godoy
- Re: Project organization and import
- From: Alex Martelli
- Project organization and import
- Prev by Date: is it possible to give an instance a value?
- Next by Date: Re: Project organization and import
- Previous by thread: Re: Project organization and import
- Next by thread: Re: Project organization and import
- Index(es):
Relevant Pages
|