Loguru Log Levels Not Fully Compatible with Python Logging's LogRecord

[yechielb2000]

First of all I want to thank you for this awesome library—it's truly outstanding! You're the best ❤️

I've discovered a bug ☹️

When using handlers in Loguru, the StandardSink allows log records to be written as LogRecord objects using logging.makeRecord.

Loguru introduces a unique way to define levels with logger.level(...) in the Core object. However, this method of saving levels doesn’t align with how Python's logging library handles levels internally. Specifically, the discrepancy causes an issue when Loguru-created log records are processed by logging.

Steps to Reproduce

1. Define custom log levels in Loguru using logger.level(...).
2. Use a handler to write the log record, leveraging logging.makeRecord.
3. Observe that levelname is incorrectly labeled in the resulting LogRecord object.

Root Cause

When creating a LogRecord, Python's logging library uses two fields: levelno and levelname. While Loguru's record['level'].no can populate levelno, the levelname field relies on logging's getLevelName function. Loguru stores level definitions in its Core object, which is incompatible with logging's method that relies on two dictionaries to store level names.

Consequently, when Loguru log levels aren’t added to logging's internal structures, getLevelName returns a default string, e.g., "Level {level_number}", since it can't find the corresponding name.

Suggested Solution

To improve compatibility, consider calling logging.addLevelName to register Loguru levels when adding a new level. This way, getLevelName will find the custom levels, and LogRecord will accurately reflect both levelno and levelname.
This solution isn’t perfect, but it will do the job until a way to pass the core parameter into StandardSink is available.

[Delgan]

Hey @yechielb2000.

Thank you for this very descriptive ticket and for the time you took to open a pull request.

If I'm not mistaken, this problem only appears when using a custom logging.Formatter(). That is, this code works as expected:

from loguru import logger
import logging

logger.remove()

standard_handler = logging.StreamHandler()

logger.add(standard_handler, format="{level.name} | {level.no} | {message}")

logger.success("This is a success message")
# => "SUCCESS | 25 | This is a success message"

But not this one:

from loguru import logger
import logging

logger.remove()

standard_formatter = logging.Formatter("%(levelname)s | %(levelno)d | %(message)s")
standard_handler = logging.StreamHandler()
standard_handler.setFormatter(standard_formatter)

logger.add(standard_handler, format="{message}")

logger.success("This is a success message")
# => "Level 25 | 25 | This is a success message"

I agree that is a surprising behavior. You're right that Loguru doesn't call logging.addLevelName(), and that's what's causing the problem demonstrated above. However, this is kind of by design.

Basically, I think Loguru should not directly interfere with the standard logging library, and in particular should not mutate any global state such as the level register.

You'll also notice that loguru and logging levels are not handled in the same way and are not fully compatible. More specifically, Loguru does not maintain a "severity to name" mapping, contrary to the standard library.

For these reasons, I would prefer to encourage the users to call logging.addLevelName() explicitly, rather than this call being implicitly made by Loguru. Surely, this should be added to the documentation.

That being said, I realize there exists another solution that do not require to call addLevelName(). Maybe we could simply update the LogRecord instance created, and basically change the levelname attribute of the standard record:

loguru/loguru/_simple_sinks.py

Lines 38 to 48 in 7ef5b67

	record = logging.getLogger().makeRecord(
	record["name"],
	record["level"].no,
	record["file"].path,
	record["line"],
	message,
	(),
	(exc.type, exc.value, exc.traceback) if exc else None,
	record["function"],
	{"extra": record["extra"]},
	)

I have to make sure it wouldn't cause any unwanted side effects, but it sounds like an acceptable workaround.

[yechielb2000]

Thank you for your feedback! I agree that my solution might not be the most optimal, and I appreciate any alternative suggestions you may have. Your idea sounds better, I will also try to find a way to update it afterwards.

[yechielb2000]

If I’m not mistaken, the root cause of this issue lies in the write function used by _sink in the handler, specifically when it's called from the StandardSink object. I observed that handlers invoking the write function of StreamSink correctly log the level name as expected.

The issue appears to stem from the use of the original makeRecord method from the logging module (logging.getLogger().makeRecord()), which seems to interfere with proper level name logging.