stderr is a lame hack?

[Erik Jones]

So, I was just taking a look at doctest.py and saw this:

Then running the module as a script will cause the examples in the
docstrings to get executed and verified:

python M.py

This won't display anything unless an example fails, in which case the
failing example(s) and the cause(s) of the failure(s) are printed to
stdout
(why not stderr? because stderr is a lame hack <0.2 wink>), and the
final
line of output is "Test failed.".


What does he mean by stderr being a lame hack?


Erik Jones

Software Developer | Emma®
(e-mail address removed)
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

 

[Aahz]

So, I was just taking a look at doctest.py and saw this:

Then running the module as a script will cause the examples in the
docstrings to get executed and verified:

python M.py

This won't display anything unless an example fails, in which case the
failing example(s) and the cause(s) of the failure(s) are printed to
stdout (why not stderr? because stderr is a lame hack <0.2 wink>), and
the final line of output is "Test failed.".

What does he mean by stderr being a lame hack?

Lessee, I can occasionally channel Guido, maybe I can channel Uncle
Timmy:

First of all, you have to remember that Uncle Timmy is an Evil Windows
abuser. Things that seem perfectly sane and normal to the rest of us
look like chaos and cruft to him (and vice-versa, of course).

The problem with stderr is that unless you understand it (which is
pretty straightforward to anyone who has drunk the Unix Kool-Aid), you
can get all kinds of unexpected output results, especially under
redirection. Without redirection, there's no way to differentiate the
combined stdout/stderr stream; contrariwise, if you redirect just stdout
with the intention of recording your test run, you'll be missing the
stderr stream in your log.