Use logger.isEnabledFor(logging.DEBUG) instead of logger.level <= logging.DEBUG for debug guards
还没有人认领这个 Issue。
评估
调研方向
首先在 slack_sdk/ 下搜索 logger.level <= logging.DEBUG,然后检查 slack_sdk/socket_mode/ 中的 Socket Mode 示例,包括 builtin/client.py 和 client.py。确定此更改仅适用于 Socket Mode,还是适用于全部约 88 处出现位置;完成的标准是调试检查使用有效的 logger 级别,并且整个项目中的这些出现位置都得到一致处理;仅在可以避免昂贵操作时保留 guards。
由索引模型根据 Issue 内容生成。
描述
Summary
Throughout Socket Mode, debug logs are guarded like this:
if self.logger.level <= logging.DEBUG:
self.logger.debug(f"... {expensive_call()} ...")
The guard exists to avoid building the message string when debug is off (the f-string argument is evaluated eagerly, before debug() can no-op it). That's a valid goal — e.g. builtin/client.py calls debug_redacted_message_string(message), and client.py calls self.message_queue.qsize() inside the message.
But logger.level is the wrong check: it's only the level explicitly set on that exact logger, defaulting to NOTSET (0). These loggers are created with logging.getLogger(__name__) and setLevel() is never called on them. So with the usual logging.basicConfig(level=logging.INFO) (which configures the root logger), logger.level stays 0, 0 <= 10 is always True, and the guard passes anyway — the expensive string still gets built. The optimization silently does nothing in the most common setup.
Suggested change
Replace:
if self.logger.level <= logging.DEBUG:
with:
if self.logger.isEnabledFor(logging.DEBUG):
isEnabledFor() uses the effective level (walking up the logger hierarchy via getEffectiveLevel()), so it correctly short-circuits when logging is configured at the root/parent — which is what the guard was meant to do.
Where the guarded message is cheap (e.g. it only interpolates an already-computed value), the guard could simply be dropped instead.
Scope
Spotted in slack_sdk/socket_mode/, but the same logger.level <= logging.DEBUG idiom appears ~88 times across ~23 files in slack_sdk/ (webhook, scim, web, audit_logs, rtm, oauth, …). isEnabledFor is currently used nowhere. Worth deciding whether to fix Socket Mode only or apply the change project-wide.
- 主要语言
- Python
- 星标
- 4k
- 派生
- 857
- 平均合并
- 22 小时 21 分钟
- 30 天内合并 PR
- 16
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
slackapi/python-slack-sdk 的其他 Issue
-
needs info server-side-issue
难度 4/5 3-5 天 新手友好度 35/100
slackapi/python-slack-sdk#1961 · 3 条评论 ·
-
auto-triage-skip discussion
难度 5/5 一周以上 新手友好度 35/100
slackapi/python-slack-sdk#1940 · 2 条评论 ·
-
chat_postMessage silently forwards thread_id to the API, so a threaded reply posts to the channel 未关闭auto-triage-skip enhancement
难度 4/5 3-5 天 新手友好度 48/100
slackapi/python-slack-sdk#1923 · 2 条评论 ·
-
auto-triage-skip bug socket-mode
难度 3/5 1-2 天 新手友好度 72/100
slackapi/python-slack-sdk#1922 · 2 条评论 ·
-
auto-triage-skip bug python web-client
难度 3/5 1-2 天 新手友好度 52/100
slackapi/python-slack-sdk#1853 · 2 条评论 ·
查看 slackapi/python-slack-sdk 的全部 Issue
相似的 Issue
-
area: harness bug status: needs-triage
难度 2/5 1-3 小时 新手友好度 75/100
Human-Agent-Society/reef#625 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 1/5 1 小时以内 新手友好度 80/100
learningequality/kolibri#15351 · 2 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
Name consistency 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
eellak/triplestore#65 · 1 条评论 ·