2.5と2.6の間のPythonロギングの非互換性

Question

次のPython 2.5と2.6の非互換性の問題を解決するのを手伝ってもらえますか？

logger.conf：

[loggers]
keys=root,aLogger,bLogger

[handlers]
keys=consoleHandler

[formatters]
keys=

[logger_root]
level=NOTSET
handlers=consoleHandler

[logger_aLogger]
level=DEBUG
handlers=consoleHandler
propagate=0
qualname=a

[logger_bLogger]
level=INFO
handlers=consoleHandler
propagate=0
qualname=b

[handler_consoleHandler]
class=StreamHandler
args=(sys.stderr,)

module_one.py：

import logging
import logging.config

logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a.submod')
b_log = logging.getLogger('b.submod')

def function_one():
    b_log.info("function_one() called.")

module_two.py：

import logging
import logging.config

logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a.submod')
b_log = logging.getLogger('b.submod')

def function_two():
    a_log.info("function_two() called.")

logger.py：

from module_one import function_one
from module_two import function_two

function_one()
function_two()

Ubuntu 9.04でのlogger.pyの呼び出しの出力：

$ python2.5 logger.py
$

$ python2.6 logger.py
function_one() called.
function_two() called.
$

Answer 1

これは2.5〜2.6の間に修正されたバグです。 fileConfig（）関数は1回限りの構成を目的としているため、複数回呼び出さないでください-ただし、これを調整することを選択します。 fileConfigの意図された動作は、構成で明示的に言及されていないロガーを無効にし、言及されたロガーとその子を有効のままにしておくことです。バグが原因で、子供が本来あるべきではないときに無効にされていました。ロガー構成の例では、ロガー「a」および「b」に言及しています。 getLogger（ 'a.submod'）を呼び出した後、子ロガーが作成されます。 2番目のfileConfig呼び出しはPython 2.5でこれを誤って無効にします-Python 2.6では、ロガーは設定で明示的に指定されたロガーの子であるため無効になりません。

Answer 2

私はこの振る舞いの理由を自分で理解していませんが、2.6であなたがよく述べたように、それは異なった働きをします。これは2.5に影響するバグだと推測できます

回避策として、以下をお勧めします：

extra_module.py：

import logging
import logging.config

logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a.submod')
b_log = logging.getLogger('b.submod')

module_one.py：

from extra_module import a_log

def function_one():
    a_log.info("function_one() called.")

module_two.py：

from extra_module import b_log

def function_two():
    b_log.info("function_two() called.")

このスキームを使用することにより、python2.5.4でlogger.pyを2.6と同じ動作で実行できました

Answer 3

おもしろい...コンソールで少し遊んだが、 logging.config.fileConfig への2番目の呼び出しが混乱しているようだ。なぜそうなったのかわからない...ここに問題を示す転写があります：

lorien$ python2.5
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> import logging.config
>>> logging.config.fileConfig('logger.conf')
>>> alog = logging.getLogger('a.submod')
>>> alog.info('foo')
foo
>>> import logging
>>> import logging.config
>>> alog.info('foo')
foo
>>> logging.config.fileConfig('logger.conf')
>>> alog.info('foo')
>>> alog = logging.getLogger('a.submod')
>>> alog.info('foo')
>>> 
>>> blog = logging.getLogger('b.submod')
>>> blog.info('foo')
foo
>>>

logging.config.fileConfig を2回目に呼び出すと、ロガーインスタンスはロギングを停止します。新しいロギングインスタンスを取得しても、同じオブジェクトであるため役に立ちません。両方の時間を設定してロガーインスタンスを取得するまで待機すると、動作します。これが blog インスタンスが動作する理由です。

機能を使用するまで、ロガーインスタンスの取得を遅らせることをお勧めします。 logging.getLogger（）への呼び出しを function_one および function_two に移動すると、すべてが正常に機能します。

Answer 4

両方のファイルでロガーの名前をそのように変更することで、これを修正できました：

logging.config.fileConfig('logger.conf')
a_log = logging.getLogger('a')
b_log = logging.getLogger('b')

正確なエラーはわかりませんが、v2.5ロガーモジュールでは、 getLogger（）に渡された名前と設定ファイルの名前を一致させるのに問題があるようです。