Finding "hidden" syntax errors

[eltronic at juno.com]

On Fri, 11 Jun 2004 13:03:38 -0500 "Larry Bates writes:
> It doesn't happen often, but once in a while I will
> introduce a syntax error into a Python program I'm
> working on (in IDLE) and doing File-Check responds
> with the expected "Failed to check, syntax error -
> invalid syntax".  The problem is where the cursor
> stops is perfectly legal syntax.  I then begin
> going through the laborious job of cutting out
> pieces of the code until I find what is wrong.  

interesting how few are willing to share their secrets on this
most time consuming with little intrinsic reward subject.
it is the weekend.
errors do show you what you think you know.

adding a line, commenting out lines, 
triple quoting out lines.
cutting out lines before and after.
anything to get rid of the syntax error.
at times like this, people may revert to
a previous favorite more native language.
or they might even search to see if anyone 
has posted some python to do the same task.

it may be hard to justify spending another hour
debugging a script to replace a perl one liner
with a dubious use case. must you continue?

save the file and get a hex view or dump.
mixing tabs and spaces can have this symptom.
sometimes the error pointer is at the top of the error
containing block, sometimes at the bottom.
python version is going to be a factor.
latest is better.
running python -tt your.py  outside the IDE.
if only to verify the IDE not a contributing factor.

compare linenumber's in more than one editor.
always blame the tools last or never.  
it is your fault! you must accept the facts.
but it doesn't hurt to perform a reality check.

use reindent and tabnanny in Tools/Scripts
hopefully Idle has some way to add these
as menu commands to run on the script buffer.

after a paste of code, in a texteditor that wraps 
you may line up the indentation not realizing
it's a line continued.  
many editors have a show control codes option.

blank lines can be suspect as they might have 
an odd number of tabs or spaces.

missing colon ':'  in for, def, if, elif, else, class
misspelling an identifyer.
usually with these the error pointer will be accurate.

forgetting 'pass' statement,
needed if you comment out the only live statements
in a try/except or if/else block

shadowing builtin names str, dict, file, list are popular,
until a few lines later you try to use the function.

turn a section of code into a function or method, 
this will often expose a dependance on a global 
that is wrecking havoc.

rearrange the code in anycase to move the error.
if 1: and indent a bunch of lines. 
a bad insinct at this point would be to continue 
refactoring without being able to test the program!
at the first sign of deep trouble you should begin 
to save copies to document the problem.

too long between runs of the code
so its hard to piece together when and where
the error might have been introduced,

incomplete test coverage.

no incremental backup
so there is no previous working file to compare to.
occasionally save or add it to a zip in a dated directory.
or use one of the source control technologies. cvs, svn.
note, this only works if you remember or its automatic.

editing is the leading cause of errors.
if you don't find an anomaly every 15 minutes
or every 100 lines, your not really trying hard enough.

its entirely possibly the current algorithm will be superseded
by further research anyway, why wait. don't sweat the small stuff.
rip out the offending code and substitute some black box data 
returned by a stub and press on.


e
please forward all spam to  uce at ftc.gov

________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!