Reason for unintuitive UnboundLocalError behaviour

Question

Note: There is a very similar question here. Bear with me, however; my question is not "Why does the error happen," but "Why was Python implemented as to throw an error in this case."

I just stumbled over this:

a = 5
def x()
    print a
    a = 6
x()

throws an UnboundLocalException. Now, I do know why that happens (later in this scope, a is bound, so a is considered local throughout the scope).

In this case:

a = 5
def x()
    print b
    b = 6
x()

this makes very much sense. But the first case has an intuitive logic to it, which is to mean this:

a = 5
def x()
    print globals()["a"]
    a = 6 # local assignment
x()

I guess there's a reason why the "intutive" version is not allowed, but what is it? Although this might be a case of "Explicit is better than implicit," fiddling around with the globals() always feels a bit unclean to me.

To put this into perspective, the actual case where this happened to me was someone else's script I had to change for one moment. In my (short-lived) change, I did some file renaming while the script was running, so I inserted

import os
os.rename("foo", "bar")

into the script. This inserting happend inside a function. The module already imported os at the top level (I didn't check that), and some os.somefunction calls where made inside the function, but before my insert. These calls obviously triggered an UnboundLocalException.

So, can someone explain the reasoning behind this implementation to me? Is it to prevent the user from making mistakes? Would the "intuitive" way just make things more complicated for the bytecode compiler? Or is there a possible ambiguity that I didn't think of?

Answer 1

Having the same, identical name refer to completely different variables within the same flow of linear code is such a mind-boggling complexity that it staggers the mind. Consider:

def aaaargh(alist):
  for x in alist:
    print a
    a = 23

what is THIS code supposed to do in your desired variant on Python? Have the a in the very same print statement refer to completely different and unrelated variables on the first leg of the loop vs the second one (assuming there IS a second one)? Have it work differently even for a one-item alist than the non-looping code would? Seriously, this way madness lies -- not even thinking of the scary implementation issues, just trying to document and teach this is something that would probably make me switch languages.

And what would be the underpinning motivation for the language, its implementers, its teachers, its learners, its practitioners, to shoulder all of this conceptual burden -- to support and encourage the semi-hidden, non-explicit use of GLOBAL VARIABLES?! That hardly seems a worthwhile goal, does it now?!

Answer 2

I believe there is a possible ambiguity.

a = 5
def x():
    print a
    a = 6  # could be local or trying to update the global variable
x()

It could be as you assumed:

a = 5
def x():
    print globals()["a"]
    a = 6 # local assignment
x()

Or it could be they want to update the global variable to 6:

a = 5
def x():
    global a
    print a
    a = 6
x()

Answer 3

This is a basic side effect of scoping. The python developers decided that global variables shouldn't be available in the scope you are trying to use it in. Take this for example:

a = 5
def x():
    a = 6
    print a
x()
print a

This outputs 6 5.

It is generally considered bad practice to have global variables anyway, so the python developers restricted this. You have to explicitly make the global variable accessible in order to access it. This is actually to prevent ambiguity. Consider this:

a = 5
def x():
    a = 6
    print a
    y()
def y():
    global a
    a = a + 1
    print a
x()
print a

If x() considered a to be local, and did the assignment, this would output 6 6 7. Whoever wrote x() may not have considered that y() would use a global variable named a. Thus causing y() to act abnormally. Luckily the python scopping makes it so that the developer of x() doesn't have to worry about how the developer of y() implemented y(), only that it does what it is supposed to. As a result, this outputs 6 6 6 (figures), like it is supposed to.

As a result, the UnboundLocalException is perfectly intuitive.