python-structured-logginglisted

# Python Structured Logging Improve logs so they are useful to operators, safe to ship, and easy to query. ## Use this workflow 1. Identify the logging stack already in use: `structlog`, stdlib `logging`, `loguru`, or a project wrapper. 2. Preserve existing conventions unless they are clearly harmful or the user asks to standardize them. 3. If `structlog` is available or already used, prefer it as the primary implementation style. 4. Prefer stable event names plus structured fields over interpolated text messages. 5. Bind shared request or task context once instead of repeating it in every call. 6. Keep one meaningful log per event boundary; remove noisy start or end chatter. 7. Preserve traceback data for unexpected failures and avoid duplicate exception logs across layers. 8. Remove or redact secrets, tokens, cookies, full payloads, and unnecessary personal data. 9. Verify changes with targeted tests or focused code inspection where possible. ## Enforce these defaults - Write event names in `snake_case`. - Keep event names short, stable, and free of variable values. - Put variable data into fields such as `user_id`, `request_id`, `duration_ms`, `status`, or `reason`. - Choose levels by operational meaning: `DEBUG` for diagnostics, `INFO` for expected events, `WARNING` for degradations or retries, `ERROR` for failed operations, `CRITICAL` only for service-threatening states. - Use unit-bearing names such as `duration_ms`, `delay_seconds`, `size_bytes`, and `timeout_seco