Trial participants generally thought the error messages were quite helpful. Sixty-nine percent either agreed or strongly agreed with the statement ``I found the error messages sufficiently helpful such that when they occurred I could quickly spot the problem'' (see Figure 3.4. Python error messages are perhaps a little verbose for the type of programs the students are asked to write. Here is an example:
>>> print a Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'a' is not defined
In general, all you need to know for a short program (i.e. one source file) is the line number the interpreter found an error on (always line 1 when running interactively) and the last line of message, which describes the nature of the error. This description is usually quite useful in diagnosing the problem. The handbook had a section on translating these error messages (which are a little esoteric at times) and IDLEfork's ability to jump straight to the suspect line was found extremely useful.
Python does raise one rather confusing error: when there is a syntax error on one line (such as a missing closing bracket) Python claims there is a syntax error on the line that follows. This is because that is the first time it encounters syntactically illegal code. Demonstrators quickly learned to spot this.
As is the case in many other languages, Python's errors are difficult to understand until you know what they mean, but once you do they are very helpful. Hopefully the appendix on errors included in the Handbook will expediate students escape from this chicken-and-egg situation. The appendix was inspired by and derived from the excellent notes included in the Livewires course, a summer camp that, amongst other things, teaches teenage children to program in Python[#!livewires!#]. Discussions with other demonstrators suggested that all of them found the messages at least satisfactory, if not better than other languages.
Unfortunately, at the time of writing, an equivalent course to teach students to program using C has not been sufficiently tested to make detailed comparisons. In the brief trials of the C course the most significant difference seemed to be the nature of the error messages. Because C is a compiled rather than interpreted language there is a qualitative difference in the origin and number of errors encountered at compilation compared to those encountered by the Python interpreter. In general, if a program contains one error the Python interpreter will stop at that error and refuse to continue. However, an equivalent error in a C program may lead to many more error messages. Although these error messages may all have the same origin and be trivially soluble, the sheer number of errors with which the student is presented has the potential to be off-putting.