Puzzling error msg.

[Ian Kelly]

On Mon, Dec 3, 2012 at 10:37 AM,  <wrw at mac.com> wrote:

>         if found_0 == True or found_1 == True:
>

Not related to your problem, but this line would be more pythonic as:

    if found_0 or found_1:

My puzzle two-fold.  First: how could that code generate an "index our of
> range" error, and second: line 101 (the one fingered by the error message)
> is the line following the return statement, the one that contains the #
> character.  I've seen that sort of line slippage when I forgot a ":", but
> that doesn't seem to be the case here.
>

It may indicate a discrepancy between the source and the code that is
actually running.  Python doesn't keep the source in memory; when a
traceback needs to be generated it opens the relevant files and reads the
designated lines at run-time.  If that source is incorrect, then you get
inaccurate tracebacks.  This could happen in a couple of ways.

1) Your .pyc or .pyo files are out-of-date, and Python doesn't realize it
due to incorrect file modification times.  Try deleting the cached bytecode
files and recompiling and see if your problem goes away (or at least gives
you a better stack trace).

2) It sounds like this is a long-running process, so perhaps the source
code has been changed at some point since the process started.  In that
case, merely restarting the process should be sufficient to fix the stack
trace.

As for the actual error, assuming that the method's source accurately
reflects what was running, the only code I see there that I think could
generate the error is the ".communicate()[0]" bit.  As far as I know,
Popen.communicate should always return a 2-tuple, but perhaps you've
somehow run into a case where it returned an empty tuple instead.  If you
can reproduce the error, you might try logging the result of the
.communicate() call to see what is actually returned when the error occurs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121203/aed53c08/attachment.html>