Why Python's Logging Library Needs a Fresh Look

If you’ve ever spent an afternoon wrestling with Python’s logging library, you know the feeling. You start with a simple import logging and a quick logging.info(), hoping for a clean log output. But then you need to add a file handler, and suddenly you’re diving into getLogger, setLevel, and configuring format strings that look like they belong in a secret codebook. It works – eventually – but the journey is rarely pleasant.

Here’s the thing: Python’s logging library is undeniably powerful. It’s been around since Python 2.3, and it’s battle-tested. But that power comes at the cost of simplicity. For the vast majority of use cases – from small scripts to medium-sized applications – the library feels like overkill. And for newcomers, it’s a steep, confusing hill to climb.

The Core Problem: Configuration is Too Complex

Let’s be honest. The most common logging task is this: “Print a timestamped message to the console, and maybe to a file.” In many modern frameworks (like structlog or even the standard library in other languages), this is a one-liner. In Python’s logging, it’s a dance.

You have to:

1. Create a logger: logger = logging.getLogger(__name__)
2. Set its level: logger.setLevel(logging.DEBUG)
3. Create a handler: handler = logging.StreamHandler()
4. Set the handler’s level (separately): handler.setLevel(logging.DEBUG)
5. Create a formatter: formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
6. Attach the formatter to the handler: handler.setFormatter(formatter)
7. Add the handler to the logger: logger.addHandler(handler)

That’s seven steps for basic logging. Seven. And if you forget to set the logger’s level, you might get no output at all – or worse, confusing output.

Compare this to a hypothetical PythonSkillset overhaul:

import pyskilog as log

log.setup(level='DEBUG', file='app.log')
log.info('Hello, world!')

Two lines. No handler wrangling, no formatter incantations. That’s the level of simplicity developers actually want.

The Mess of Child Loggers and Propagation

One of the most confusing aspects of the current library is how loggers interact. If you create a logger in a module like myproject.module, and another in myproject, they automatically “propagate” messages up the hierarchy. That sounds nice in theory, but in practice it leads to duplicated logs, missing logs, and hours of debugging.

For example:

# In main.py
import logging
logging.basicConfig(level=logging.INFO)

# In module.py
logger = logging.getLogger(__name__)
logger.info('This appears once?')

You might expect one log message. But if you also configure a handler in module.py, you could get two. The propagation mechanism is powerful, yes, but it’s also a silent footgun.

Many developers end up disabling propagation entirely with logger.propagate = False, which kind of defeats the purpose of having a hierarchy in the first place.

Where the Library Shines (and Where It Doesn’t)

To be fair, the logging library does some things very well:

• Separation of concerns: Loggers, handlers, filters, and formatters are distinct concepts.
• Extensibility: You can write custom handlers for Slack, databases, or whatever you need.
• Contextual logging: With LogRecord and filters, you can add metadata.

But these strengths are overshadowed by the complexity of basic use. The library was designed for large enterprise systems where you need fine-grained control over logging. For the rest of us – the Python developers building APIs, data pipelines, or small scripts – it’s like using a chain saw to cut butter.

What an Overhaul Should Look Like

A modern logging library for Python should do three things:

1. Make the common case dead simple – One function call to log to console and file, with sensible defaults. No handlers, no formatters unless you want them.

2. Use modern Python idioms – Leverage dataclasses for configuration, type hints, and async support for logging in asynchronous applications. The current library predates asyncio and it shows.

3. Be friendly to beginners – Documentation that shows the “happy path” first, not a dozen edge cases. The current docs are comprehensive but overwhelming.

Imagine a PythonSkillset tutorial where a new user types:

from pyskilog import Logger

log = Logger(level='info', format='compact')
log.info('User signed in', user_id=42)

And they get:

2025-04-08 14:32:01 INFO User signed in (user_id=42)

No boilerplate. No confusion. Just clean, usable logging.

The Reality Check

Will the Python core team overhaul the logging library? Probably not soon. The library is stable, widely used, and any breaking change would upset millions of lines of production code. But that doesn’t mean we can’t wish for better. The future of Python logging might be third-party libraries like loguru or structlog, which already solve these problems with cleaner APIs.

Perhaps it’s time for PythonSkillset to champion a modern logging approach in tutorials. Show readers how to use loguru instead of wrestling with the standard library. Or build a lightweight wrapper that makes the common case easy.

Because at the end of the day, logging shouldn’t be a barrier to getting your code to run. It should be the thing that helps you understand what your code is doing – quickly, clearly, and without pain.

What’s your experience with Python’s logging library? Have you found workarounds that make it more usable? Join the conversation on PythonSkillset.