[Python-ideas] Structured Error Output

[Bryce Boe]

> And we're telling you that no, the changes you're interested in are
> not trivial - the use of stderr is embedded deep within many parts of
> the interpreter.

This is the first constructive comment I've received thus far. Perhaps
I am a bit optimistic that grepping for output to stderr and replacing
the write or fprintf calls with a function call would be appropriate.
Maybe a tedious procedure, but it still seems trivial. It's not like
trying to replace the GIL ;)

> I suggest just raising the bar for your students and require that they
> write their errors to both stderr *and* to an error log. Interpreter
> generated errors will show up in the former, but will never appear in
> the latter.

The example I gave was simply an example. Sure we could ask the
students to more, but ideally this tool would work on any recent
python source without requiring source modification. Many of these
solutions have been presented before, however, they fail to work in
the general case.

> Oh, I work with such cases often enough to know that if they've got a
> complete programming language as a tool, you've already lost.
> And if the people writing the code are antagonistic, there is no way
> to differentiate those behaviors. Anything the python interpreter can
> do the programmer can also do. And, for that matter, suppress.

I realize that even if there was another output stream the user could
write to it via, os.write(3, "foobar"), however, static checks can be
made on the code to detect such function calls. Also, I'm curious, can
a python program suppress later syntax errors?

>> That is a generalization which is not true. Counter example: I have
>> students writing a simple interpreter in python and their compiler
>> should output syntax errors to stderr when the program their
>> interpreter is interpreting. Now say their errors looks very similar
>> to python errors, how does one distinguish between an error in their
>> implementation of their interpreter, or an error raised by their
>> interpreter?

> That's not writing data to stderr, that's writing errors. The problem
> in this case is that the program in question isn't handling errors in
> the implementation properly.  If your students aren't bright enough to
> figure out how to catch errors in their implementation and flag them
> as such, flunk them.

Again this was just a contrived example that demonstrates my want to
differentiate between the two. Whether or not the students get stuck
isn't the problem, the problem is that it's not possible to do the
differentiation. But simply put, why not allow for such
differentiation? What is lost by doing so?

> Trying to get all language processors to produce similar error
> messages is tilting at windmills.  The existence of IDE's that parse
> error message and let the user go through them in order hasn't been
> sufficient to cause that to happen. Some abstract wish to study
> beginners errors will have even less effect.

It is my opinion that most people make due with what they have
available to them. Of course, I can do exactly what I want to do
without modifying the interpreter, however, it suffers from the
ambiguity problem I've already mentioned. One of the great things
about open source software is the ability to adapt it to suit your own
needs, and thus I prefer to take the approach of making things better.
Perhaps no one before me has even considered separating interpreter
output from the programs that the interpreter interprets, but I find
that quite hard to believe. This really isn't a problem with compiled
code, because the compilation and type checking process is separate
from the execution process, though I'll admit there is the same
problem with runtime errors such as segmentation faults but these can
be discovered with proper signal handling.

> But you claim the structure is the import part.  Want to give an
> example of how you would "structure the error output" so that errors
> in a program processing program source can be distinguished from
> errors in the processed source, yet at the same time be similar enough
> so that some tool could be used on both sets of errors?

First, the two changes should work in tandem thus both interpreters
would have a flag, say --structured-error-output that takes a
filename. With such a flag directing the error output to different
files is quite trivial. However, even if they went to the same stream
(poor design in my opinion) the structured messages can have an
attribute indicating which interpreter produced the message thus
allowing for differentiation. Of course, if they went to the same
stream, then you still have the possibility of spoofing the other
program which is why the separation is necessary.

Anyway, I appreciate the argument. It is fairly clear that if I were
to implement this support it is not something that would be integrated
in python thus it's not worth my time. I'll take the band-aid approach
as everyone before me has.

Thanks,
Bryce