This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mbussonn
Recipients martin.panter, mbussonn, r.david.murray, rhettinger, serhiy.storchaka
Date 2017-02-17.18:30:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1487356221.24.0.541883873671.issue29593@psf.upfronthosting.co.za>
In-reply-to
Content
> Wouldn't be better to say just "local variable 'xxx' is not set"?

Thank you for responding that fast and for your interest in this issue. 

While I think that "local variable 'xxx' is not set" is technically correct, I think it would be a step back.

The improvement of the error message is not really meant for the 99% of the developers hanging on b.p.o. I think for these just the fact that there is an UnboundLocalError is sufficient to know what's happening. 

The error message will mostly be useful for users that still don't have much clue about what's going on. For these kind of users UnboundLocalError("local variable 'xxx' is not set") is not much different from NameError("name 'xxx' is not defined")[*]

The current error message already does a good job at giving some extra hint as to why this is the case. In particular that it is (often) assigned but not in the right place. Changing to "local variable 'xxx' is not set" will likely make many novices check the spelling, and be more confused.

Note that "local variable 'xxx' referenced before assignment, or got deleted" would not be completely obvious for novices either, why would the following not trigger such an error ? 

In [1]: def foo():
   ...:     if False:
   ...:         print(n)
   ...:     n = 1

Well, for you and me it's (likely) obvious. 

I want to point out (just stealing rhettinger example) that it might not be obvious either the variable has been deleted:

In [5]: def foo():
   ...:     n = 1 
   ...:     def g(): # imagine a more complex g
   ...:         del n 
   ...:     g()
   ...:     print(n) #UnboundLocalError
   ...:

So I think expanding the error message to give hints as of _why_ is better than just stating what is. 


[*] Source: The users I work with. Last question I got on wednesday: "Can you re-explain the difference between a string and a function". They meant "list" and "list comprehension".
History
Date User Action Args
2017-02-17 18:30:21mbussonnsetrecipients: + mbussonn, rhettinger, r.david.murray, martin.panter, serhiy.storchaka
2017-02-17 18:30:21mbussonnsetmessageid: <1487356221.24.0.541883873671.issue29593@psf.upfronthosting.co.za>
2017-02-17 18:30:21mbussonnlinkissue29593 messages
2017-02-17 18:30:20mbussonncreate