Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Fechada
  • Algo errado?
#1,957 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 5 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
api, backend

Direção de pesquisa

Comece pesquisando por logger.level <= logging.DEBUG em slack_sdk/ e, em seguida, inspecione os exemplos de Socket Mode em slack_sdk/socket_mode/, incluindo builtin/client.py e client.py. Decida se a mudança se aplica apenas ao Socket Mode ou a todas as aproximadamente 88 ocorrências; considera-se concluído quando as verificações de debug usam os níveis efetivos do logger e as ocorrências em todo o projeto são tratadas de forma consistente, mantendo os guards apenas onde evitam trabalho dispendioso.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
4k
Forks
861
Merge médio
3d 17h
PRs com merge (30d)
11

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de slackapi/python-slack-sdk

Todas as issues de slackapi/python-slack-sdk

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.