Python 何时使用sys.stdout而不是sys.stderr？

我的老板让我查看一些旧代码，其中所有内容都被发送到stderr。我知道stderr应该有警告和错误，但是什么时候它们真的应该转到stdout呢

这个程序是一种服务。它发送给stderr的一些消息是：

if pid is None:
    message = "pidfile {0} is not running. \n"
    sys.stderr.write(message.format(self.pidfile))

这是一个输出，对吗？关于成功与否的消息应该转到标准输出，因为它不是错误

然后我得到了另一个例外：

except OSError as err:
    sys.stderr.write('fork #1 failed: {0}\n'.format(err))
    sys.exit(1)

这是一个例外，所以应该转到stderr，因为这是一个错误？或者它应该转到stdout，因为它是一条输出消息，只是说程序失败了

我知道stdout和stderr是什么——我在问之前读了很多书。我这里的问题是能够识别哪些消息应该发送到stderr——仅仅是致命错误，还是任何类型的错误消息

---

这两个示例都是错误消息，但其中一个只是“程序未运行”。我在选择此类消息的发送位置时遇到问题。

致命错误肯定会转到stderr。正常输出应转到标准输出

信息性消息有一个灰色区域，但一般来说，如果它们会导致输出不可用，则不应转到标准输出。人们通常将stdout指向一个文件，将stderr指向终端或日志文件

---

你需要决定哪种划分最有意义。

汤姆·卡泽斯已经给了你一个正确的答案，但要说明一个更极端的立场

我发现将

stdout

和

stderr

视为“标准输出”和“标准非输出”会有所帮助。您说过您认为消息“应该转到

stdout

，因为它不是一个错误”，但这是向后的：

stdout

是具有高进入壁垒的流，而不是

stderr

消息应转到

stderr

（或日志文件，或除

stdout

以外的任何内容），除非它是所需输出的一部分，即用户实际需要的最终产品。如果你不能用“用户要求…”开头的一句话来证明其包含的合理性，那么不要用它来污染stdout。（管道中的下一个流程将感谢您。）

很有可能，你的用户没有运行你的程序，因为他们想看一个旋转的指挥棒，或者读一打“试图重新连接…”的消息，甚至想知道哪个fork失败了，所以这些不应该在

stdout

上

---

最后，有些消息不应该发送到任何一个输出流

stderr

可能是由用户读取的，所以请尝试将其输出限制为用户现在关心的内容。保持它没有“正常情况”消息，除非用户通过打开详细信息（通常是

--verbose

或

--debug

）明确请求。至少允许用户使用

--quiet

或

--silent

选项使非错误静音。大多数“信息性”消息应发送到日志文件，而不是控制台。

可能重复的致命错误肯定应发送到stderr。正常输出应转到标准输出。信息性消息有一个灰色区域，但一般来说，如果它们会导致输出不可用，则不应转到标准输出。人们通常将stdout指向一个文件，将stderr指向终端或日志文件。所以你需要决定什么划分最有意义。@TomKarzes：把它作为一个答案。比dup Q更具信息性。将标准输出视为您的程序所做的，将标准错误视为您的程序所做的。程序输出的实际数据应转到stdout，所有元数据（如错误消息和进度报告）应转到stderr。所以“fork#1失败”应该转到stderr，类似“fork#1成功”的东西也应该转到stderr。“pidfile{0}未运行”也应该转到stderr。我喜欢这样想：标准输出是指程序所做的，标准错误是指程序所做的。明白了。第一个只是一个输出，表示未运行，因此不是错误消息。另一个是致命的，应该去stderr。@chepner，这很有帮助。我们将尝试使用它作为其他方法。谢谢大家。@Dkage，stderr不仅仅限于错误消息；它通常用于元数据。任何提供信息而不是实际输出数据（您希望在读取生成内容的另一个程序中解析）的内容都属于stderr。