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.