Use logger.isEnabledFor(logging.DEBUG) instead of logger.level <= logging.DEBUG for debug guards

Aperta
#1,957 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api, backend

Direzione di ricerca

Inizia cercando logger.level <= logging.DEBUG in slack_sdk/, quindi esamina gli esempi di Socket Mode in slack_sdk/socket_mode/, inclusi builtin/client.py e client.py. Determina se la modifica si applica solo a Socket Mode o a tutte le circa 88 occorrenze; il lavoro è completato quando i controlli di debug usano i livelli effettivi del logger e le occorrenze nell’intero progetto sono gestite in modo coerente, mantenendo le guards solo dove evitano lavoro costoso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

auto-triage-skip bug

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.

Lingua principale
Python
Stelle
4k
Fork
857
Merge medio
22h 21m
PR unite (30g)
16

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di slackapi/python-slack-sdk

Tutte le issue di slackapi/python-slack-sdk

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.