[Python-ideas] Structured Error Output
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("__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?
exec "x = )("
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,
More information about the Python-ideas