日志包的改进 [英] improvements for the logging package

问题描述

在我目前的项目中处理某些事情我已经对Python中的日志包进行了几次改进，其中两个是值得的

提及：

1.添加日志记录字段％（函数）s，结果

名称
$记录记录的实体的b $ b。我的版本甚至在记录器是绑定方法的情况下推断出

类名，并且假设

是self的名称。变量确实是自我。


出于性能原因，此功能可以关闭，并且对于调试阶段非常有用

。


2.日志着色格式化程序（对控制台输出很有用） - 支持日志

行，如BLUE<< text>>等。


现在，我问过我的几个经常使用Python编程的朋友，并且他们告诉我他们可以非常使用这些功能。


我在这里冒风险，也许有人已经在这个组中提出了这个问题，但是我会问任何一种方式：

有没有人想过发布一个关于此的PEP？你认为我应该吗？


我已经很好地利用了日志包，肯定会看到它发展并包含更多功能。

Hi,

while working on something in my current project I have made several
improvements to the logging package in Python, two of them are worth
mentioning:
1. addition of a logging record field %(function)s, which results in
the name
of the entity which logged the record. My version even deduces the
class name in the case which the logger is a bound method, and assuming
the name of the "self" variable is indeed "self".

This ability can be turned off, for performance reasons, and is useful
for debugging phases.

2. log coloring formatter (useful for console output) - support for log
lines like BLUE<<text>>, etc.

Now, I asked several friends of mine who program in Python often, and
they told me they could use these features very much.

I''m taking a risk here, that maybe someone already proposed this in
this group, but I''ll ask either way:
Has anyone thought of posting a PEP about this? Do you think I should?

I have made a great use of the logging package, and would certainly
like to see it evolve and include more features.

推荐答案

[Rotem写的]

[Rotem wrote]

在我当前的项目中处理某些事情我已经做了几个<对Python中的日志包的改进，其中两个值得提及：
1.添加一个日志记录字段％（function）s，其结果是名称<记录记录的实体的br />。我的版本甚至在记录器是绑定方法的情况下推断出
类名，并假设自我的名称。变量确实是自我。

出于性能原因，可以关闭此功能，并且对于调试阶段非常有用。

2.日志着色formatter（对于控制台输出很有用） - 支持BLUE<<<>>等日志

现在，我问了我的几个朋友，他们经常用Python编程，并且他们告诉我他们可以非常使用这些功能。

我在这里冒风险，也许有人已经在这个小组中提出了这个，但是我我会问任何一种方式：
有没有人想过发布关于此的PEP？你觉得我应该吗？


酷。你的添加听起来很有用。

对于PEP来说这可能有点小（虽然我不是权威）。

你可以在SourceForge上的新bug上发布你的补丁。

http://sourceforge.net/tracker/ ？group_id = 5470

我已经充分利用了日志包，并且肯定希望看到它发展并包含更多功能。

while working on something in my current project I have made several
improvements to the logging package in Python, two of them are worth
mentioning:
1. addition of a logging record field %(function)s, which results in
the name
of the entity which logged the record. My version even deduces the
class name in the case which the logger is a bound method, and assuming
the name of the "self" variable is indeed "self".

This ability can be turned off, for performance reasons, and is useful
for debugging phases.

2. log coloring formatter (useful for console output) - support for log
lines like BLUE<<text>>, etc.

Now, I asked several friends of mine who program in Python often, and
they told me they could use these features very much.

I''m taking a risk here, that maybe someone already proposed this in
this group, but I''ll ask either way:
Has anyone thought of posting a PEP about this? Do you think I should?
Cool. Your additions sound useful.
This might be a bit small for a PEP (though I am hardly an authority).
You could post your patch on a new bug on SourceForge.

http://sourceforge.net/tracker/?group_id=5470
I have made a great use of the logging package, and would certainly
like to see it evolve and include more features.

需要考虑的事情有助于获得更多的日志包

用来写下你的经验：写一个教程或

HOWTO或核心日志记录文档的改进。目前，日志记录

包看起来对新用户来说相当不吸引人/不可用。


干杯

Trent

-

Trent Mick
Tr **** @ActiveState.com

在我当前项目中处理某些事情时，我做了几处改进在Python中的日志包中，其中两个值得提及：

while working on something in my current project I have made several
improvements to the logging package in Python, two of them are worth
mentioning:

...

Trent>凉。你的添加听起来很有用。


也许是这样，但是日志记录模块看起来像是一个unpythonic的野兽。在我们添加更多之前清理它（*）怎么样？好像

着色似乎属于它自己的模块（假设一个合理的

一般标记方案可以达成一致）所以它可以在
之外使用
日志包。


（*）对我来说似乎很奇怪的东西：


- 这是一个包，但是与我见过的任何其他软件包相反，大多数功能都是在__init__.py中实现的。 __init__.py是

大约是下一个最大的两倍（bsddb，这是一个

野兽，因为多年来BerkDB已经变得如此之大以及

模块/包已经努力保持向后兼容）。


- 它仍然太难用了。显而易见的''hello world''示例


导入日志

logging.info（''hello world''）


应该正常工作（隐式添加连接到

stderr的流处理程序到根记录器）。


- 其功能有时被分区奇怪的方式。例如，

它有一个处理程序模块，但我认为是最常用的
常用处理程序（StreamHandler）在那里没有定义。它在

（你有三个猜测，前两个不算数）__init__.py

而不是logging.handlers。因此，以明显的

方式浏览无法找到StreamHandler类。


- 就命名而言，它没有使用PEP 8样式相反，

做某种Java或C ++或Perl camelCase的事情。避免PEP

8适用于其他东西，但Python核心中的代码（特别是新的

代码，如日志记录模块）应该努力遵守PEP 8，因为

很多人会将核心代码用作自己代码的模式。


Skip

...
Trent> Cool. Your additions sound useful.

Perhaps so, but the logging module seems like such an unpythonic beast to
me. How about cleaning it up (*) before we add more to it? Stuff like
colorizing seems like it belongs in its own module (presuming a reasonably
general markup scheme can be agreed upon) so it can be used outside the
logging package.

(*) Stuff that seems very odd to me:

- It''s a package, but contrary to any other package I''ve ever seen, most
of its functionality is implemented in __init__.py. __init__.py is
roughly four times larger than the next largest (bsddb, which is a
beast because BerkDB has gotten so big over the years and the
module/package has strived to remain backwards-compatible).

- It''s still too hard to use. The obvious ''hello world'' example

import logging
logging.info(''hello world'')

ought to just work (implicitly add a stream handler connected to
stderr to the root logger).

- Its functionality is partitioned in sometimes odd ways. For example,
it has a handlers module, but what I presume would be the most
commonly used handler (StreamHandler) is not defined there. It''s in
(you have three guesses and the first two don''t count) __init__.py
instead of in logging.handlers. Consequently, browsing in the obvious
way fails to find the StreamHandler class.

- It doesn''t use PEP 8 style as far as naming is concerned, instead
doing some sort of Java or C++ or Perl camelCase thing. Eschewing PEP
8 is fine for other stuff, but code in the Python core (especially new
code like the logging module) should strive to adhere to PEP 8, since
many people will use the core code as a pattern for their own code.

Skip

[sk**@pobox.com写道]

[sk**@pobox.com wrote]

也许是这样，但是日志模块看起来像是一个如此无声的野兽。在我们添加更多之前清理它（*）怎么样？


是的。我还试图鼓励Rotem参与其他部分

的日志模块/包稍后在我的电子邮件中。 :)

像着色一样的东西似乎属于它自己的模块
（假设一个合理的通用标记方案可以达成一致）所以
它可以在日志包之外使用。


呀，你可能是对的。对记录系统的大多数添加都可以轻松地作为他们自己独立的部分生活。

（*）对我来说这看起来很奇怪的东西：

- 这是一个包，但与我见过的任何其他包相反，它的大多数功能都是在__init__.py中实现的。 __init__.py比下一个最大的bsddb大四倍（bsddb，这是一个野兽，因为多年来BerkDB已经变得如此之大，而且
模块/包已经努力保持倒退-兼容）。


我不是在捍卫实施，但是这会导致任何特定的问题吗？


显而易见的''hello world''示例

导入日志
logging.info（''hello world''）

应该正常工作（隐式添加流处理程序连接到
stderr到根记录器）。


也许。除非这会导致实际使用的麻烦。像这样懒惰

配置意味着它可以是一个微妙的东西，用于设置正确的日志配置的顶级应用程序代码。


当我看到这个呈现为hello world

的例子时，我有点畏缩。我的基本问候世界往往是：


导入日志记录

log = logging.getLogger（" name-of-my-module-or-script" ）


＃在模块/脚本中使用log。{debug | info | warn | error}（）...

＃...


if __name__ ==" __ main __"：

logging.basicConfig（）

＃...

然后我希望我的

最常用的默认输出更好一些 - 这是在脚本中登录到命令行 -

而不是看起来更喜欢网络服务器错误/访问日志。


我认为日志模块的可用性可以通过

a更好的介绍得到很大改善它（即文档）。它不是一个真正的hello world

类型的工具。它的用处仅在更大的用例中显示。


- 它的功能有时以奇怪的方式划分。例如，
它有一个处理程序模块，但我认为最常用的处理程序（StreamHandler）并没有在那里定义。它在
（你有三个猜测，前两个不算数）__init__.py
而不是logging.handlers。因此，以明显的方式浏览无法找到StreamHandler类。

- 就命名而言，它没有使用PEP 8样式，而是做了一些某种Java或C ++或Perl camelCase的东西。避免PEP
8适用于其他东西，但Python核心中的代码（特别是新的
代码，如日志记录模块）应该努力遵守PEP 8，因为很多人会使用核心代码作为自己代码的模式。

Perhaps so, but the logging module seems like such an unpythonic beast to
me. How about cleaning it up (*) before we add more to it?
Yes. I was also trying to encourage Rotem to get involved in other parts
of the logging module/package later on in my email. :)
Stuff like colorizing seems like it belongs in its own module
(presuming a reasonably general markup scheme can be agreed upon) so
it can be used outside the logging package.
Yah, you are probably right. Most additions to the logging system could
easily live as their own separate pieces.
(*) Stuff that seems very odd to me:

- It''s a package, but contrary to any other package I''ve ever seen, most
of its functionality is implemented in __init__.py. __init__.py is
roughly four times larger than the next largest (bsddb, which is a
beast because BerkDB has gotten so big over the years and the
module/package has strived to remain backwards-compatible).
I''m not defending the implementation, but does this cause any particular
problems?

The obvious ''hello world'' example

import logging
logging.info(''hello world'')

ought to just work (implicitly add a stream handler connected to
stderr to the root logger).
Maybe. Unless that causes troubles for real use. Having lazy
configuration like this means that it can be a subtle thing for
top-level application code to setup the proper logging configuration.

I cringe a little bit when I see this presented as the "hello world"
example. My basic hello world tends to be:

import logging
log = logging.getLogger("name-of-my-module-or-script")

# use log.{debug|info|warn|error}() in module/script...
#...

if __name__ == "__main__":
logging.basicConfig()
#...

and then I wish again that the default output were a bit nicer for my
most common usage -- which is logging to the command line in scripts --
rather than looking more like to web server error/access logs.

I think the usability of the logging module could be much improved with
a nicer introduction to it (i.e. docs). It''s not really a "hello world"
type of tool. Its usefulness only really shows in larger use cases.

- Its functionality is partitioned in sometimes odd ways. For example,
it has a handlers module, but what I presume would be the most
commonly used handler (StreamHandler) is not defined there. It''s in
(you have three guesses and the first two don''t count) __init__.py
instead of in logging.handlers. Consequently, browsing in the obvious
way fails to find the StreamHandler class.

- It doesn''t use PEP 8 style as far as naming is concerned, instead
doing some sort of Java or C++ or Perl camelCase thing. Eschewing PEP
8 is fine for other stuff, but code in the Python core (especially new
code like the logging module) should strive to adhere to PEP 8, since
many people will use the core code as a pattern for their own code.

也许Vijay（谁做了所有的实现）都可以评论这些。

不幸的是倒退-compat可能会限制一些清理到

包，但也许不会太多。在我开始初步设计之后，我做了一个很差的工作来跟上包装的原因，并且从Java的log4j包中复制了一个初始的

设计（和我甚至不是一个Java家伙。 :(


Trent


-

Trent Mick
Tr **** @ActiveState.com

这篇关于日志包的改进的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！