所以我想將日誌記錄添加到我一直維護的一個小內部命令行實用程序中。 (實際上,我將它轉換爲相當難看的手動編碼日誌記錄以使用Python的logging
模塊;並且沿途清理了一些瑕疵)。Python:如何從OptionParser type ='count'logging.setLevel詳細程度?
首先,我想保留現有的行爲,疣和所有,遺留使用。任何可能取決於它已經發出的無關警告的腳本都不應該因我在做什麼而中斷。新功能應通過-v
開關,在OptionParser中實現爲type=count
(按照古老的Unix/Linux約定)。這裏的摺痕是,一個單獨的-v
將詳細程度從-1設置爲0(零)...諷刺地壓制來自Paramiko庫的至少一個警告消息(對於記錄器「paramiko.transport」找到沒有處理程序可以是 )。從那裏我想支持多達四個額外的-v
選項,並使用那些logging.setLevel()
逐步更詳細,從logging.CRITICAL
只有下降到logging.DEBUG
。
有蹭!
我可以很容易地使用類似:
if opts.verbosity == 0: # default is -1 do NOTHING
# 0 ironically makes it slightly quieter
logging.getLogger().addHandler(logging.NullHandler())
elif opts.verbosity > 0:
logging.basicConfig()
logging.getLogger().setLevel(50 - min(40, 10*opts.verbosity))
# UGLY BUT IT WORKS.
# logging.CRITICAL is 50,
# each -v reduces log filter by 10 down to 10
換句話說,我將我的-v
開關的數量爲十的倍數減去由最低冗長下來,對最詳細的。 (順便提一句,這是Python2.7.x)。
我注意到,logging.basicConfig()
消除了「找不到句柄」的警告,並且暴露了一些基本的錯誤消息,只要該實用程序在生產(年)中已經(無害地)發生了。 (所以,如果我的默認值爲0,正如人們所期望的那樣,那麼我會向用戶介紹一些令人震驚的噪音。
但是我的問題是:是否有更「適當」的方式從數字的冗長設置成logging.setLevel()
翻譯?這似乎髒使用此實現細節(與logging.CRITICAL, logging.ERROR, logging.WARN,...
等相關的數值)。
當然我不能使用-vvv
唯一一個Python的標準OptionParser
和logging
模塊但是閱讀docs和谷歌搜索沒有找到任何這種「最佳實踐」。