This post would have been more appropriate on python-list than python-dev. But to answer your implied questions... On 10/31/2012 3:57 PM, anatoly techtonik wrote:

Here is the code:

---[cut]-----------------------------

DEBUG = [] FONT_NAMES = []

This line has nothing to do with the behavior of the function that follows. The error message would be the name if it were deleted.

def names(): if len(DEBUG): print(len(DEBUG)) if len(FONT_NAMES): print(len(FONT_NAMES)) if len(FONT_NAMES)==0: FONT_NAMES = "query()"

This makes FONT_NAMES a local name *everywhere* within names.

names() ---[cut]-----------------------------

Here is the output:

Traceback (most recent call last): File "globalocal.py", line 13, in <module> names() File "globalocal.py", line 8, in names if len(FONT_NAMES): UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment

As you may see there is inconsistency between handling of line 6 - "if len(DEBUG):" and line 8 - "if len(FONT_NAMES):".

No there is not.

This is very magical and hard to troubleshoot.

Names (not 'variables') within a function are deterministically classified at compile time as local, nonlocal, or global according to declarations and usage *within the function*. This classification has nothing to do with names in other namespaces and is done independently of other namespaces. The rules are described in the manuals.

I wonder if this message can be improved with a pointer to the concept on when global variables become local?

This never happens. Global names stay global (until deleted). They may be masked by a local name with the same spelling (as in your example), but that is a different issue. -- Terry Jan Reedy

On 10/31/2012 4:28 PM, R. David Murray wrote:

"local variable referenced before assignment" *is* a pointer to the concept of when global variables become local...perhaps there is a better wording, do you have a suggestion?

The current wording is an exact, concise, description of the problem. Rather than tinkering with the wording, I think a more general solution might be a new HOWTO: Understanding exception messages. It could have alphabetically sorted entries for exceptions and messages that people find problematic. UnboundLocalError local variable referenced before assignment Problem: You used a local name 'x' in an expression before you assigned it a value. So the interpreter could not compute the value of the expression. Remember that assignment makes a name local unless it is declared global or nonlocal. Remedy: If you intend 'x' to refer to a glocal or nonlocal name, add the necessary global or nonlocal declaration. If you intend -- Terry Jan Reedy

On 10/31/2012 9:20 PM, Terry Reedy wrote:

On 10/31/2012 4:28 PM, R. David Murray wrote:

...

"local variable referenced before assignment" *is* a pointer to the concept of when global variables become local...perhaps there is a better wording, do you have a suggestion?

The current wording is an exact, concise, description of the problem. Rather than tinkering with the wording, I think a more general solution might be a new HOWTO: Understanding exception messages. It could have alphabetically sorted entries for exceptions and messages that people find problematic.

UnboundLocalError local variable referenced before assignment

Problem: You used a local name 'x' in an expression before you assigned it a value. So the interpreter could not compute the value of the expression. Remember that assignment makes a name local unless it is declared global or nonlocal.

Remedy: If you intend 'x' to refer to a glocal or nonlocal name, add the necessary global or nonlocal declaration. If you intend <left out> 'x' to be local, rearrange your code to give it a value before you use it.

-- Terry Jan Reedy

Am 31.10.2012 23:15, schrieb Steven D'Aprano:

On 01/11/12 06:57, anatoly techtonik wrote: [...]

...

UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment [...] I wonder if this message can be improved with a pointer to the concept on when global variables become local?

If you have a suggestion for an improved message, please tell us.

I'll take a shot, since I was also bitten by this when trying to learn Python. The important point is that some code earlier or later in that function does an assignment, so this location should be referenced in the error. How about: "UnboundLocalError: Local variable 'FONT_NAMES' (created on line 11) referenced before assignment." What I don't really like is the term "created". Maybe "implicitly created on line 11"? Or "implied by line 11"? Or how about "Local variable FONT_NAMES (implied by line 11) doesn't refer to an object", to avoid the multiple interpretations of the term "assignment"? =just my 2cc= Uli ************************************************************************************** Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at http://www.dominolaser.com ************************************************************************************** Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden. E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich. **************************************************************************************

How about:

"UnboundLocalError: Local variable 'FONT_NAMES' (created on line 11) referenced before assignment."

What I don't really like is the term "created". Maybe "implicitly created on line 11"? Or "implied by line 11"? Or how about "Local variable FONT_NAMES (implied by line 11) doesn't refer to an object", to avoid the multiple interpretations of the term "assignment"?

It's been a long (long) while since I looked at the virtual machine implementation, but my guess is that at the point where the error is detected the system won't know what line number corresponds to the assignment. There might also be multiple assignments. How would you know which one to pick? As for a better word than "created", I would use "assigned." Skip

On Wed, Nov 7, 2012 at 11:57 PM, Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> wrote:

How about:

"UnboundLocalError: Local variable 'FONT_NAMES' (created on line 11) referenced before assignment."

What I don't really like is the term "created". Maybe "implicitly created on line 11"? Or "implied by line 11"? Or how about "Local variable FONT_NAMES (implied by line 11) doesn't refer to an object", to avoid the multiple interpretations of the term "assignment"?

Unfortunately, we don't track the information we would need in order to emit that kind of error message. However, you did give me an idea: I believe the compiler is actually in a position to emit SyntaxWarning for functions that have a high chance of triggering UnboundLocalError when called. With output pointing to *both* problematic lines, beginners should stand a better chance of figuring out what is going on. (http://bugs.python.org/issue16429) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 11/12/2012 7:30 AM, Jan Matějek wrote:

I believe the "human problem" here is that the one tends to gloss over "local variable VARNAME", because it describes VARNAME and you already think you know what that is, so you don't stop to think about it.

The following would be better in this regard, IMO:

"Variable VARNAME is local in FUNCNAME, but doesn't have a value at line 123"

+1