[Python-ideas] Structured Error Output

Steven D'Aprano steve at pearwood.info
Thu Apr 26 04:44:01 CEST 2012


On Wed, Apr 25, 2012 at 07:04:15PM -0700, Bryce Boe 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.

I don't think so. Or at least, not easily.

funcs = [len, str, eval, map]
value = funcs[2]("__imp" + "port"[1:] + "__('sys')")
f = getattr(value, ''.join(map(chr, (115, 116, 100, 101, 114, 114))))
y = getattr(f, ''.join(map(chr, (119, 114, 105, 116, 101))))
y("statically check this!\n")


> Also, I'm curious, can
> a python program suppress later syntax errors?

try:
    exec "x = )("
except SyntaxError:
    print("nothing to see here, move along")


[...]
> 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?

Apart from simplicity?

You risk infinite regress. stderr exists to differentiate "good" output 
from "error" output. So you propose a new stream to differentiate "good 
errors" (those raised by the students' interpreter, call it stderr2) 
from "bad errors" (those raised by the interpreter running the students' 
interpreter). At some point, someone will have some compelling (to them, 
not necessarily everyone else) use-case that needs to distinguish 
between "real" good errors going to stderr2 and "fake" good errors going 
to stderr2, and propose stderr3. And deeper and deeper down the rabbit 
hole we go...

At some point, people will just say "Enough!". I suggest that the 
distinction between stdout and stderr is exactly that point.

(Although, having said that, I wish there was a stdinfo for 
informational messages that are neither the intended program output nor 
unintended program errors, e.g. status messages, progress indicators, 
etc.)



-- 
Steven



More information about the Python-ideas mailing list