'break' Causes Execution of Procedure?

[Scott Brady Drummonds]

Hi, everyone,

I have a bug in a script of several hundred lines of code that I cannot
figure out. I have attempted (unsuccessfully ) to duplicate this problem in
a smaller script that I can post here but have been unsuccessful. As such,
I'm posting code snippets here in the hopes that someone recognizes a very
basic mistake I've made and can straighten me out.

First, the portion of my text file that executes my code:

<quote>
if __name__ == '__main__':
if len(sys.argv) != 2:
print('usage: %s <config_file> ' % sys.argv[0])
sys.exit()

main(sys.argv[1])
</quote>

Here are the first few lines of my 'main' procedure:
<quote>
def main(fileName):
print('DEBUG: begin main procedure')
...
</quote>

And here is the part that is causing problems:
<quote>
# 'keys' is a list of integers returned from dict.keys()
for cycle in keys:
if key in skipList:
print ('skipping %d/%d' % (cycle, cycleMap[cycle]))
continue
try:
print('DEBUG: advancing both simulators to %d' % cycle)
procedureThatCo uldRaiseEOFErro r()
except EOFError:
print('DEBUG: encountered EOFError; breaking loop')
break
print('DEBUG: All cycles processed')
</quote>

Here's what I can't figure out. I'm seeing the following text generated
during this script's execution:
<quote>
DEBUG: advancing both simulators to 20178
DEBUG: encountered EOFError; breaking loop
DEBUG: begin main procedure
</quote>

How is it possible that the call to 'break' is seemingly being replaced with
a call to 'main'?

Thanks!
Scott

--
Remove .nospam from my e-mail address to mail me.

[Peter Otten]

Scott Brady Drummonds wrote:

I have a bug in a script of several hundred lines of code that I cannot
figure out. I have attempted (unsuccessfully ) to duplicate this problem
in
a smaller script that I can post here but have been unsuccessful. As
such, I'm posting code snippets here in the hopes that someone recognizes
a very basic mistake I've made and can straighten me out.
Unfortunately you seem to have picked the wrong snippets, which by the way
look made-up. The only error I see

if key in skipList:
...

should probably be

if cycle in skipList:
....

The "most basic" error would be a print statement producing
DEBUG: begin main procedure
sitting in a second place where it doesn't belong and isn't expected.
How is it possible that the call to 'break' is seemingly being replaced
with a call to 'main'?

Other than with a buggy C-extension that is not possible.

Peter

[Scott Brady Drummonds]

"Scott Brady Drummonds" <sc************ **********@inte l.com> wrote in
message news:cf******** **@news01.intel .com...

How is it possible that the call to 'break' is seemingly being replaced with a call to 'main'?

I should also point out that the second time that the program's execution
reaches the 'break' statement in the 'main' procedure, I get the following
cryptic error message:

<quote>
DEBUG: advancing both simulators to 20178
DEBUG: encountered EOFError; breaking loop
XXX lineno: 109, opcode: 0
Traceback (most recent call last):
File "test.py", line 135, in ?
main(sys.argv[1])
File "test.py", line 109, in main
break
SystemError: unknown opcode
</quote>

What's going on here?

Scott

--
Remove .nospam from my e-mail address to mail me.

[Peter Hansen]

Scott Brady Drummonds wrote:

I should also point out that the second time that the program's execution
reaches the 'break' statement in the 'main' procedure, I get the following
cryptic error message:

<quote>
DEBUG: advancing both simulators to 20178
DEBUG: encountered EOFError; breaking loop
XXX lineno: 109, opcode: 0
Traceback (most recent call last):
File "test.py", line 135, in ?
main(sys.argv[1])
File "test.py", line 109, in main
break
SystemError: unknown opcode
</quote>

What's going on here?

Scrambled .pyc file? Try deleting all .pyc files in the folder
and rerun. (Just a thought.)

[Jeff Shannon]

Scott Brady Drummonds wrote:

Hi, everyone,

I have a bug in a script of several hundred lines of code that I cannot
figure out. I have attempted (unsuccessfully ) to duplicate this problem in
a smaller script that I can post here but have been unsuccessful. As such,
I'm posting code snippets here in the hopes that someone recognizes a very
basic mistake I've made and can straighten me out.

First, the portion of my text file that executes my code:

<quote>
if __name__ == '__main__':
if len(sys.argv) != 2:
print('usage: %s <config_file> ' % sys.argv[0])
sys.exit()

main(sys.argv[1])
</quote>

Here are the first few lines of my 'main' procedure:
<quote>
def main(fileName):
print('DEBUG: begin main procedure')
...
</quote>

And here is the part that is causing problems:
<quote>
# 'keys' is a list of integers returned from dict.keys()
for cycle in keys:
if key in skipList:
print ('skipping %d/%d' % (cycle, cycleMap[cycle]))
continue
try:
print('DEBUG: advancing both simulators to %d' % cycle)
procedureThatCo uldRaiseEOFErro r()
except EOFError:
print('DEBUG: encountered EOFError; breaking loop')
break
print('DEBUG: All cycles processed')
</quote>

Here's what I can't figure out. I'm seeing the following text generated
during this script's execution:
<quote>
DEBUG: advancing both simulators to 20178
DEBUG: encountered EOFError; breaking loop
DEBUG: begin main procedure
</quote>

How is it possible that the call to 'break' is seemingly being replaced with
a call to 'main'?

I suspect that the answer is in the context of the for loop. Try
posting a bit more of the surrounding code. (For example, it's not at
all clear how your loop relates to the main() snippet that you posted...)

Actually, I'm wondering why you catch the exception inside the loop, and
then exit the loop. If you wrapped that entire loop in the try/except,
then you wouldn't need to worry about using break -- an exception would
end the loop and *then* get dealt with.

Jeff Shannon
Technician/Programmer
Credit International

[Scott Brady Drummonds]

"Peter Hansen" <pe***@engcorp. com> wrote in message
news:t8******** ************@po wergate.ca...

Scrambled .pyc file? Try deleting all .pyc files in the folder
and rerun. (Just a thought.)

Yeah, I tried that before, as well. No such luck.

Scott

[Scott Brady Drummonds]

"Peter Otten" <__*******@web. de> wrote in message
news:cf******** *****@news.t-online.com...

Unfortunately you seem to have picked the wrong snippets, which by the way
look made-up. The only error I see
Yeah, that was a typo. I certainly would prefer to post real failing code
as opposed to code snippits, but I needed a way of distilling the importat
parts out of the program. Sorry for doing a bad job of that.
The "most basic" error would be a print statement producing

DEBUG: begin main procedure

sitting in a second place where it doesn't belong and isn't expected.

Right. You've got the idea. There's no reason why the print statement at
the first line of main() should be executed after the break statement. It
doesn't make sense.

How is it possible that the call to 'break' is seemingly being replaced
with a call to 'main'?

Other than with a buggy C-extension that is not possible.

What is equally more confounding is that I cannot duplicate this error with
a small case I can post here. :( I'm still trying, though...

Scott
--
Remove .nospam from my e-mail address to mail me.

[Scott Brady Drummonds]

"Jeff Shannon" <je**@ccvcorp.c om> wrote in message
news:10******** *****@corp.supe rnews.com...

I suspect that the answer is in the context of the for loop. Try
posting a bit more of the surrounding code. (For example, it's not at
all clear how your loop relates to the main() snippet that you posted...)
Sorry. I know that it's better to post actual failing code is much better
than snippets for exactly this reason. However, there is so much code that
I believe to be superfluous to this problem that I really wanted to make the
post simpler. To answer your question, the loop that I posted occurred in
the main() loop. That is, calling 'break' inside this loop resulted in a
call to the function that 'break' was called in (which happens to be
main()).
Actually, I'm wondering why you catch the exception inside the loop, and
then exit the loop. If you wrapped that entire loop in the try/except,
then you wouldn't need to worry about using break -- an exception would
end the loop and *then* get dealt with.

After reading your suggestion, I'm wondering why I caught the exception in
the loop as opposed to outside of the loop. I changed the implementation as
you suggested and my program is now working correctly. Of course, something
tells me that I just covered up a bug as opposed to removing it.

Scott
--
Remove .nospam from my e-mail address to mail me.

[Jeff Shannon]

Scott Brady Drummonds wrote:

After reading your suggestion, I'm wondering why I caught the exception in
the loop as opposed to outside of the loop. I changed the implementation as
you suggested and my program is now working correctly. Of course, something
tells me that I just covered up a bug as opposed to removing it.

Probably you're right about that. Better to use your original code to
figure out what's going wrong, than to proceed with changed code that
might not fix the problem. Once you've found the bug, *then* you can
switch to catching the exception outside of the loop. ;)

If your main() function has so much code, then try breaking that down
into several smaller functions. It's almost certain that you can break
a large function into several logical "sections"; if you make each of
those sections into a separate function, it'll probably be easier to
isolate the specific problem.

As an example, you could probably isolate that for loop within a
subfunction --

def ProcessCycleMap (cycleMap, keys, skipList):
for cycle in keys:
....

You may also want to go through your code and verify that you don't have
anyplace that mixes tabs and spaces, which can lead to invisibly
mismatched indentation. It may be that the compiler sees your code
structure a bit differently than you do... (Best procedure here is to
simply run tabnanny.py over your code.)

Jeff Shannon
Technician/Programmer
Credit International

[John J. Lee]

"Scott Brady Drummonds" <sc************ **********@inte l.com> writes:
[...]

DEBUG: advancing both simulators to 20178

[...]

Is this a threaded program?
John