[Python-ideas] Structured Error Output

Mike Meyer mwm at mired.org
Thu Apr 26 06:18:12 CEST 2012

Bryce Boe <bboe at cs.ucsb.edu> wrote:

>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?

Yes, a python program can supporess later syntax errors.

>This really isn't a problem with compiled
>code, because the compilation and type checking process is separate
>from the execution process

For sorting out error messages in modern languages, compilation and execution
are not necessarily separate.  You can get compilation errors at pretty much any
point in the execution of the program. Most such languages - include python, but also
include languages that compile to machine or JVM code - include both the ability to
import uncompiled source, compiling it along the way, and the ability to compile and
run code fragments (aka "eval")  in the program. Both of these can generate compilation
errors in the middle of runtime. If my proram imports a config modules the user provided
and it has a syntax error in it, is that syntax error a runtime error or a compilation error?

>> 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
>> 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 different errors to different
>files is quite trivial. 

It is? How do you distinguish between an actual syntax error and a syntax
error raised by an explicit raise statement? And which of those two cases
would a syntax error raised by passing a bad code fragment to eval be, or
is that a third case requiring  yet another flag?

>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.

I'm still waiting for a proposal solid enough to evaluate. I like the idea
of more structured error output, and think it might be a nice addition to
the interpreter. A python programmer already has complete control over
all error messages, though it can be hard to get to. Making that easier is
a worthy goal, but it's got to be more than the ability to send some ill-defined
set of exceptions to a different output stream.


Sent from my Android tablet. Please excuse my swyping.

More information about the Python-ideas mailing list