By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,389 Members | 1,989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,389 IT Pros & Developers. It's quick & easy.

Can local function access local variables in main program?

P: n/a
I am confused by the following program:

def f():
print x
x=12345
f()

result is:
>>>
12345

however:
def f():
print x
x=0

x=12345
f()

result is:
Traceback (most recent call last):
File "...\test.py", line 5, in ?
f()
File "...\test.py", line 2, in f
print x
UnboundLocalError: local variable 'x' referenced before assignment
I am using
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]
on win32
I also tested it on python 2.5, which gives the same result.

Nov 3 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On Sat, 03 Nov 2007 07:18:17 +0000, Sullivan WxPyQtKinter wrote:
def f():
print x
x=0

x=12345
f()

result is:
Traceback (most recent call last):
File "...\test.py", line 5, in ?
f()
File "...\test.py", line 2, in f
print x
UnboundLocalError: local variable 'x' referenced before assignment

When Python compiles your function f(), it sees that you have assigned to
x, and that there is no line "global x", so it knows that x is a local
variable.

But when you call f(), you try to print x before the local x has a value
assigned to it. Hence the (accurate but hardly user-friendly) error
message.

You can also do this:
>>help(UnboundLocalError)
Help on class UnboundLocalError in module exceptions:

class UnboundLocalError(NameError)
| Local name referenced but not bound to a value.

As far as I know, there is no way to read the value of global x if and
only if local x doesn't exist.

--
Steven
Nov 3 '07 #2

P: n/a
On Sat, 03 Nov 2007 07:18:17 +0000, Sullivan WxPyQtKinter wrote:
I am confused by the following program:

def f():
print x
x=12345
f()

result is:
>>>>
12345
If python can't discover x in your current scope and you do not bind to
it there, it will automatically access that global name x.
however:
def f():
print x
x=0

x=12345
f()

result is:
Traceback (most recent call last):
File "...\test.py", line 5, in ?
f()
File "...\test.py", line 2, in f
print x
UnboundLocalError: local variable 'x' referenced before assignment
Here, you *do* assign to x in this scope so this is essentially the same
as the following (without any function scope)::

print x
x = 12345

This can't work since you haven't used x when you try to print it.

You can make this work using the `global` statement::
>>def foo():
... global x
... print x
... x = 0
...
>>x = 12345
print x
12345
>>foo()
12345
>>print x
0

See more in the `lexical reference about the global statement <http://
docs.python.org/ref/global.html>.

HTH,
Stargaming
Nov 3 '07 #3

P: n/a
Sullivan WxPyQtKinter wrote:
UnboundLocalError: local variable 'x' referenced before assignment
For your reference:

http://groups.google.de/groups?q=gro...oundLocalError

Regards,
Björn

--
BOFH excuse #12:

dry joints on cable plug

Nov 3 '07 #4

P: n/a
Actually I am quite satisfied with and error, which is my expectation.
But the implicit global variable access seems quite uncomfortable to
me. Why is that necessary?

On Nov 3, 3:39 am, Stargaming <stargam...@gmail.comwrote:
On Sat, 03 Nov 2007 07:18:17 +0000, Sullivan WxPyQtKinter wrote:
I am confused by the following program:
def f():
print x
x=12345
f()
result is:
12345

If python can't discover x in your current scope and you do not bind to
it there, it will automatically access that global name x.
Nov 3 '07 #5

P: n/a
Stargaming wrote:
You can make this work using the `global` statement::
>>def foo():
... global x
... print x
... x = 0
Is there any way to disable global for x? Something like that:
>>x = 12345
def foo():
.... global x
.... print x
.... noglobal(x) # ???
.... x = 0 # now this is local x
>>foo()
12345
>>print x
12345

--
In pariete - manus et crus cerebrumque

Nov 3 '07 #6

P: n/a
On Nov 3, 2007, at 5:32 PM, Pawel wrote:
Stargaming wrote:
>You can make this work using the `global` statement::
>>>>def foo():
... global x
... print x
... x = 0

Is there any way to disable global for x? Something like that:
>>>x = 12345
def foo():
... global x
... print x
... noglobal(x) # ???
... x = 0 # now this is local x
>>>foo()
12345
>>>print x
12345
Why would you need to do that? It would be confusing. Just use a
different variable name for the local.

Erik Jones

Software Developer | Emma®
er**@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
Nov 3 '07 #7

P: n/a
Pawel wrote:
Is there any way to disable global for x? Something like that:
>>>x = 12345
def foo():
... global x
... print x
... noglobal(x) # ???
... x = 0 # now this is local x
Not really. Why don't you choose meaningful variable names? You
practically save nothing by using fewer names.

Regards,
Björn

--
BOFH excuse #423:

It's not RFC-822 compliant.

Nov 4 '07 #8

P: n/a
On 2007-11-03, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On Sat, 03 Nov 2007 17:30:45 -0000, Sullivan WxPyQtKinter
<su***********@gmail.comdeclaimed the following in comp.lang.python:
>Actually I am quite satisfied with and error, which is my expectation.
But the implicit global variable access seems quite uncomfortable to
me. Why is that necessary?

Would you want to have to write things like:
Well it would be explicit and explicit is better than implicit.
import os
import os.path
import sys

def dFunc(more):
return "The full path of the item is: %s" % more

def aFunc(something):
global os.path
global sys
global dFunc
sys.stdout.write(dFunc(os.path.join("nonsense", something)))

Your "variable" follows the same logic used for name look ups of all
items -- "read" access will, after exhausting the local scope, search
the module level names (note that you don't need "global" to modify a
mutable object in module level -- it is only the rebinding of the name
itself that needs "global")
--
Antoon Pardon
Nov 8 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.