问题陈述

Question

我有一个应用程序（python，如果它很重要），它解析文件并可能在解析过程中产生错误。发生这种情况时，我会将错误发生的位置记录到stderr并正常退出。

当我向stderr写入位置时，我必须在记录的绝对路径和相对路径之间进行选择。

当stderr是控制台时，我需要权衡相对路径之间的短路和可读性，当stderr重定向到日志文件并稍后检查时，绝对路径是明确的。

我现在拥有什么

我现在正在做的事情归结为这个

def clean_path(path):
    rpath = os.path.relpath(path, '.')
    if len(rpath) < len(path):
        path = rpath
    return os.path.normpath(path)

然后我将结果格式化为

的一部分

<filename>, lineno <lineno>: <message>

并将其写入stderr或程序配置中指定的日志文件。通常是stderr。

我查看了GNU标准，http://www.gnu.org/prep/standards/standards.html#Errors ，他们没有具体说明。它们也偏离了我在其他地方看到的上述格式 - 虽然我现在不记得在哪里。

GCC总是使用传递给GCC的文件名，但出于实现原因，我操作的大多数文件都是绝对路径。

Bash解释器错误甚至不指定文件。

我找不到任何指定这种python日志记录标准的PEP，但在快速测试中，pep8和flake8似乎遵循GNU标准。

似乎GNU标准是事实上的标准，但不是每个人都遵循它（惊喜！）。实际情况是这样吗？

鉴于我使用的大多数路径都会在错误记录代码与它们交互之前被标准化为绝对路径，那么我将专门处理这种情况视为糟糕的做法吗？

Answer 1

GNU ＆＃34;标准＆＃34; 实际上只是一套指导方针。但是，正如你已经恰当地注意到的那样，并非所有人都遵循它。事实上，我敢说除了GNU项目之外，很少有人关注它。

话虽这么说，你似乎自己做了研究。由于没有就此主题达成共识，我想说的是简单地使您的应用程序易于使用。你似乎做出的决定，使用它：

<filename>, lineno <lineno>: <message>

似乎相当合理。我还会添加你的应用程序的名称，错误的类型和该行的代码，有点像这样：

<appname>: Parsing Error: <message>
    In <filename>, line <lineno>: <code>

最后，不要将错误写入日志文件（除非用户以某种方式指定他们想要的;即：命令行选项）。相反，将所有错误写入stderr。如果用户希望，他们可以手动将stderr传递给这样的文件：

$ python <appname>.py 2><appname>.log

，让我们说，您的应用被称为parser，看起来像：

$ python parser.py 2>parser.log