Project organization and import

[Jorge Godoy]

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>