Just good advice? = WAS("Re: getting system date")

[Bengt Richter]

On Sun, 11 May 2003 05:50:07 GMT, "David Broadwell" <anti-spam.dbroadwell at mindspring.com> wrote:

>
>"Terry Reedy" <tjreedy at udel.edu> wrote in message
>news:S0CdnRakruvh3yCjXTWcpw at comcast.com...
>> I know this was answered for you, but to be successful with Python,
>> learn to use the interpreter interactively and especially the
>> type(obj) builtin function.  'print type(x)' is also an important
>> debugging tool in pre-written scripts.
>
>Can I take that to mean that type errors are a major pitfall to many
>programmers and that I should be learning to avoid them?
>
>If so: Suggestions?
>
I second the advice to use the interpreter interactively to find out
what is going wrong. But I think there is a general principle involved
that seems to be ignored in many newbie posts, namely the need for analysis,
by which I mean (from the first 2 wordnet senses):

"""
The noun analysis has 6 senses (first 3 from tagged texts)

1. analysis -- (an investigation of the component parts of a whole)
2. analysis, analytic thinking -- (the abstract separation of a whole into its constituent parts
 for study)
...
"""

IOW, if you don't understand what's going on, tackle a smaller chunk. Do an interactive
example of any statement that you're not 100% sure of just by looking at it. If you get
a surprise, try the terms of expressions separately, etc.

Walk through your code step by step if you have to, or if it's big, put in a print statement
to check if things are what you think they should be at some point in the middle. Then continue
the "lions in Africa" search on where the problem is by putting print statements in the failing
part to divide it down to smaller suspect regions, and so forth. Chances are you will see something
obvious before you get down to one line, but sometimes not (especially in the case of "one-liners" ;-)

For one-liners, build it up from simple beginnings, checking results interactively at each stage.

Note that it is a pain to retype stuff, so you'll want to set yourself up to avoid that. That's
where writing explicit tests is good, so you can just type xxx.py (or ./xxx.py) and get results
from your latest change. This also avoids fooling yourself with leftover state in an interactive
session. If you have a suitable editor (e.g., vim, emacs) you can configure the editor to save
your latest, run the program, and capture the result, for an even handier test cycle.

You may also want to look into the unittest module, for automating tests in a systematic way.

Also, the MSVC++ IDE will let you set up a test cycle that can include C/C++ extensions as well as
.py stuff, and potentially custom pre- and post- processing for various steps in a rebuild. I.e.,
essentially what you can do with nmake (or make). I am not aware of a free GUI IDE (including the
debugger and its various windows, in particular) to match it, unfortunately.

Python's pdb module can be used also, though I confess I haven't used it much. I probably should
familiarize myself more.

Regards,
Bengt Richter