Hello,

I was running a very main memory intensive program in my computer. I looked for similar bugs or troubles in the site and I didn't found any similar to this. I know that the use of global variables is not recommended by software engineering, but for special cases it is very fast to develop/test some ideas.

My problem statement is the following (very simplified and also attached):

########## BEGINNING OF CODE
#test for globals

counter_1 = 0

def modifierfunction():
    global counter_1

    #some code
    counter_1 += 1
    #some other code

def test():
    for i in range(2):
        global counter_1
        counter_1 = 0

        for j in range(10):
            modifierfunction()

        print "COUNTER_1:", counter_1

def test2():
    global counter_1
    for i in range(2):
        counter_1 = 0

        for j in range(10):
            modifierfunction()

        print "COUNTER_1:", counter_1

if __name__ == "__main__":
    test()
    test2()
########## END OF CODE

Globally speaking, it is a global variable, defined at the begining of the python file (counter_1), and it is modified in some functions within it (in this example, modifierfunction). At the end, it appear some tests that make what I need. 

If you try to run this code, it will always show the expected values in the standard out. But, let me to show you my problem.

In the beginning, I have the global statement as in test2. But I found that it only take a corrent value for the first iteration. The others it has always a zero value. I didn't understand anything.

Then, some collegue suggested me to change the place of the global statement (as in test()), and then it worked correctly, as it was expected.

I repeat. The above example works fine. But when this same structure, but with my big problem, very main memory intensive, test2() didn't work correctly.

Thank you for your attention.

Regards,

Jordi

If you really think there is a bug, don't post working code, post code that actually demonstrates the problem. Something anyone else could use to reproduce the bug.

The resulting bytecode the functions are compiled to is exactly the same, no matter where the global statement is.

So I cannot believe that moving the global statement alone causes something that failed to work.

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).