On 16 March 2013 18:27, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
>
> Sometimes many levels of trace messages can be helpful when detecting bugs,
> however, in the case of NameErrors, these "nuggets" ejected from deep within
> the bowls of the Python interpreter are nothing more than steaming piles of
> incomprehensible crap!
>
> We don't need multiple layers of traces for NameErrors. Python does not have
> *real* global variables; and thank Guido for that! All we need to know is
> which module the error occurred in AND which line of that module contains the
> offensive lookup of a name that does not exist.
[SNIP]
NameErrors can occur conditionally depending on e.g. the arguments to
a function. Consider the following script:
# tmp.py
def broken(x):
if x > 2:
print(x)
else:
print(undefined_name)
broken(1)
When run it gives a NameError with a traceback:
$ python tmp.py
Traceback (most recent call last):
File "tmp3.py", line 8, in <module>
broken(1)
File "tmp3.py", line 6, in broken
print(undefined_name)
NameError: global name 'undefined_name' is not defined
The traceback shows the arguments passed to the broken function that
caused the NameError to be generated. Different arguments would not
have generated the NameError. This information can be useful if the
logic of the function in question is complicated. It also hints at why
you were calling the function and what your code is trying to do.
Oscar
--
http://mail.python.org/mailman/listinfo/python-list
