Patch by Tim Peters: Introduce a new builtin exception, UnboundLocalError, raised when ceval.c tries to retrieve or delete a local name that isn't bound to a value. Currently raises NameError, which makes this behavior a FAQ since the same error is raised for "missing" global names too: when the user has a global of the same name as the unbound local, NameError makes no sense to them. Even in the absence of shadowing, knowing whether a bogus name is local or global is a real aid to quick understanding. Example: D:\src\PCbuild>type local.py x = 42 def f(): print x x = 13 return x f() D:\src\PCbuild>python local.py Traceback (innermost last): File "local.py", line 8, in ? f() File "local.py", line 4, in f print x UnboundLocalError: x D:\src\PCbuild> Note that UnboundLocalError is a subclass of NameError, for compatibility with existing class-exception code that may be trying to catch this as a NameError. Unfortunately, I see no way to make this wholly compatible with -X (see comments in bltinmodule.c): under -X, [UnboundLocalError is an alias for NameError --GvR]. [The ceval.c patch differs slightly from the second version that Tim submitted; I decided not to raise UnboundLocalError for DELETE_NAME, only for DELETE_LOCAL. DELETE_NAME is only generated at the module level, and since at that level a NameError is raised for referencing an undefined name, it should also be raised for deleting one.]

--- a/Python/ceval.c	Mon Jun 21 22:36:53 1999 +0000
+++ b/Python/ceval.c	Tue Jun 22 14:47:32 1999 +0000
@@ -1320,7 +1320,7 @@
 		case LOAD_FAST:
 			x = GETLOCAL(oparg);
 			if (x == NULL) {
-				PyErr_SetObject(PyExc_NameError,
+				PyErr_SetObject(PyExc_UnboundLocalError,
 					   PyTuple_GetItem(co->co_varnames,
 							oparg));
 				break;
@@ -1338,7 +1338,7 @@
 		case DELETE_FAST:
 			x = GETLOCAL(oparg);
 			if (x == NULL) {
-				PyErr_SetObject(PyExc_NameError,
+				PyErr_SetObject(PyExc_UnboundLocalError,
 					   PyTuple_GetItem(co->co_varnames,
 							oparg));
 				break;