This is the same command as before, except I prepended it with a
! to tell the debugger that this is Python code, which it needs to
evaluate, rather than a debugger command. Because the debugger knows this is
Python code to evaluate, it doesn't try to execute a do_for()
method and generate an exception.

The line self.tmp_dict[key] = int(l[i]) raised a ValueError
exception because it could not covert "9" to an int? That is
really weird. Sometimes, things aren't exactly what they seem, though.
What exactly was the input? Take a look:

(Pdb) !print l[i]
9

That looks pretty normal to me. When I didn't feed l[i] to
print, what happened?

(Pdb) !l[i]
'9\x089'

The mystery is pretty much over. The input data contained some funky values
that masked themselves. I did the same thing with some_string
(which was a single input line from the data file):

(Pdb) !print some_string
1 2 3 4 5 6 7 8 9 10

This looked pretty normal as well. Here it is when I don't
print it:

(Pdb) !some_string
'1 2 3 4 5 6 7 8 9\x089 10'

The \x08 character is \b, a backspace, so when the code prints out the input line, it prints 1 2 3 4 5 6 7 8 9,
backspaces over the 9, and then prints out 9 10. If you
ask the interpreter what the value of the input line is, it shows you the
string value--including the hex value of unprintable characters.

The ValueError exception is totally expectable in this
situation. Here is the result, at a debugger prompt, of trying to get the integer
value of the same kind of string:

(Pdb) int("9\b9")
*** ValueError: invalid literal for int(): 9

The problem with the example code boils down to a couple of things:

It handles exceptions at too high a level.

It doesn't clean up properly when the code hits an exception.

The first item (improper exception handling) caused the code to create a
dictionary of part of the corrupt input line. It created a dictionary with keys
of 0 through 7.

The second item (improper cleanup) caused the code to use the dictionary
that existed from the corrupt line (line 2 from the input data file) for the
following line (line 3 from the input data file). That is why the first
1 2 3 4 line contained dictionary keys of 0 through
7 rather than 0 through 3.
Interestingly, if the code handled the exception of converting a string to an
int properly, cleaning up would not have been an issue.

Here is a better version of the code, which does better exception handling and
cleans up better in the case of a catastrophic error: