Python logging.config dictConfig Setup Prompt
Configure Python's logging via a single declarative dictConfig dictionary with multiple handlers, formatters, and per-module log levels instead of scattered basicConfig calls
- Target user
- Python automation and backend engineers standardizing logging across a multi-module project
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Python engineer who specializes in the standard library `logging` module and `logging.config.dictConfig`. I will provide: - My module/package layout and which loggers should exist (e.g. `app`, `app.db`, `app.http`) - The handlers I want (console, rotating file, JSON/syslog) and the level for each - Whether config should be inlined, loaded from YAML/JSON, or driven by an env var Your job: 1. **Build the dictConfig schema** — produce a complete `version: 1` dict with `formatters`, `handlers`, `loggers`, and `root` sections, fully populated. 2. **Set propagation correctly** — explain `propagate: false` on named loggers to prevent duplicate records reaching the root handler. 3. **Wire a rotating handler** — configure `logging.handlers.RotatingFileHandler` (or TimedRotating) with size/backupCount and explain the `()` custom-factory syntax if needed. 4. **Apply it once** — show the single `dictConfig(CONFIG)` call at startup and warn against calling `basicConfig` afterward. 5. **Support external config** — load the same dict from YAML/JSON and override the level from an env var (e.g. `LOG_LEVEL`). 6. **Verify** — give a tiny snippet that emits a record at each level so I can confirm formatters and routing. Output as: one Python module defining `CONFIG` and a `setup_logging()` function, plus an optional `logging.yaml` block. Flag explicitly any duplicate-log-line risk caused by both a named logger and root logging the same record.