Puzzling error msg.

[wrw at mac.com]

On Dec 3, 2012, at 1:27 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:

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

Thanks Ian - yes, Steven pointed out the same thing.  Point well taken.

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

It is a long-running process, and because of exactly that point I'm pretty careful about source code management.  You will notice that the original traceback contained the code link: "Version2.2/WorkingCopy/network.py".  In other words, I'm pretty careful about segregating my development copies from the code I leave running.

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

I was kind of afraid it might be something like that.  I've added some print statements and I'll just have to wait for it to fail again (hopefully soon).

Thanks again,
Bill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121203/0cb71713/attachment.html>