gpt4 book ai didi

python - 是否有一种标准的 UNIX 方式可以明确地将 写入 stderr?

转载 作者:行者123 更新时间:2023-11-28 19:21:03 25 4
gpt4 key购买 nike

问题陈述

我有一个应用程序(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>

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

缺乏明显的共识

我看过 GNU 标准,http://www.gnu.org/prep/standards/standards.html#Errors, 他们没有具体说明。它们也偏离了上述格式,我在别处看到过这种格式——尽管我现在记不起在哪里了。

GCC 始终使用传递给 GCC 的文件名,但出于实现原因,我正在操作的大部分文件将是绝对路径。

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

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


GNU 标准似乎是事实上的标准,但并不是每个人都遵循它(惊讶!)。真的是这样吗?

鉴于我使用的大多数路径在错误记录代码与它们交互之前都会被规范化为绝对路径,专门处理这个问题会被视为不良做法吗?

最佳答案

GNU “标准” 实际上只是一套指南。但是,正如您恰本地注意到的那样,并不是每个人都遵循它。事实上,我敢说在 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

关于python - 是否有一种标准的 UNIX 方式可以明确地将 <filename> 和 <lineno> 写入 stderr?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24967295/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com