Re: Finding "hidden" syntax errors

Discussion in 'Python' started by eltronic@juno.com, Jun 13, 2004.

  1. Guest

    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

    ________________________________________________________________
    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!
    , Jun 13, 2004
    #1
    1. Advertising

  2. Eru Guest

    escribio:
    >
    > 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.

    >
    > [ some advice about error checking -- snipped ]


    Another problem that arises from time to time which produces the effect
    described by the OP is an "unclosed parens", that is, a parens that was
    open and never closed (or a square bracket).

    As Python considers an unclosed parens as an implicit continuation of
    the statement in the following line, the error is often "detected" in
    some place PAST the actual error.

    Something similar happens with "unclosed strings", but any editor with a
    decent syntax highlighting makes you notice this almost instantly.

    My advice is to explore your editor and learn if there is some way to
    get "help" with your parents. Emacs does this veri well AFAIK, and in
    Vim you can

    :set showmatch

    to get Vim show you some highlights about parens; you can also press %
    when you are on a parens to move to the corresponding (opening/closing)
    one.

    My .02 :)

    --
    Daniel Ripolles ( Eru )
    Make Source, Not War
    for(0..pop){for($c=$_%2;$_>>=1;){$c=$_%2 .$c}print"$c\n"}
    Eru, Jun 14, 2004
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    941
    Mark Goldin
    Jan 17, 2004
  2. Larry Bates

    Finding "hidden" syntax errors

    Larry Bates, Jun 11, 2004, in forum: Python
    Replies:
    1
    Views:
    356
    Miki Tebeka
    Jun 13, 2004
  3. yawnmoth
    Replies:
    97
    Views:
    4,699
    Bent C Dalager
    Feb 27, 2009
  4. Rick
    Replies:
    3
    Views:
    8,142
    Alexey Smirnov
    Apr 13, 2010
  5. SolarCanine
    Replies:
    2
    Views:
    272
    SolarCanine
    Sep 20, 2005
Loading...

Share This Page