[bringing back on-list]
On 05/10/2014 07:30 PM, Devin Jeanpierre wrote:
On Sat, May 10, 2014 at 2:38 PM, Ethan Furman firstname.lastname@example.org wrote:
On 05/10/2014 02:03 PM, Devin Jeanpierre wrote: > >
spam is referring to a local variable that has not been bound. This is not an implementation detail.
The implementation detail is that in cpython there is a spot already reserved for what will be the 'spam' variable, as opposed to the module level where no such spots are reserved.
I don't know what a "spot reserved" would even mean in a language spec, so sure. But Chris did not bring up the idea of a "reserved spot" in the post you were responding to, and I didn't either. Chris claimed that Python had unbound variables, you disagreed, and I pointed at the docs, which agree with Chris systematically.
Chris was claiming that the exception UnboundLocalError, with complete text of:
UnboundLocalError: local variable 'not_here' referenced before assignment
is saying that the local variable does exist before it is assigned to; it is my contention that it does not. UnboundLocalError came into existence to aid in debugging a specific subclass of errors , and the text was chosen for that specific purpose.
Because module level variables work differently from local variables.
Not by language definition. There are pythons where modifying function locals works, but the working or not-working is not a language guarantee.
I did make the mistake of saying "locals", when I meant "function-level locals". That was wrong.
Um, what other kind of locals are there?
"Raised when a reference is made to a local variable in a function or method, but no value has been bound to that variable."
Hmm, looks like a doc-patch is needed. ;)
Seriously though, error messages are chosen to provide a simple and clear description that will help the user track down what went wrong, not for enshrining in exact detail the language semantics. Would you really rather have:
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in func UnboundLocalError: the name 'not_here' does not yet exist as you have not yet assigned anything to it so there is currently no variable by that name although at some point (in the future of this function, or perhaps in a branch that has been passed and did not execute) you will or did assign something to it so it will exist in the future of this function or may exist at this point in a future run of this function.
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in func UnboundLocalError: local variable 'not_here' referenced before assignment
 The conditions being that a variable was referenced before is was created, but the text of NameError offered no help in figuring that out ("what do you mean it doesn't exist?!? It's right there!")