Lightbus' logging system needs a major refactoring, or perhaps completely tearing our and reimplementing. It was one of the first areas implemented and I've been papering over the cracks since then.
I've marked this as a 'good first issue', but the caveat being that you'll need a decent understanding of Python's logging system.
Existing problems
- Cannot use placeholders in log messages (e.g.
%). This means all messages must be formatted strings, regardless of whether the message will be logged or not. This impacts performance.
Existing features (to keep)
I want the following (currently existing) features to also be present in the new system:
- Coloured output based on log level (TTY only)
- Emoji output (TTY only) – May sound silly, but this has really helped me scan through the logging output
- Bold text (TTY only)
- Bulleted lists (TTY only)
New features
Addendum
Having reviewing the logging code it actually doesn't look too bad. I'd be tempted to:
- Refactor
LBullets into LogList and LogMapping
- Separate out logic for rendering to tty vs non-tty.
- Go through the code and refactor/document anything non-obvious
Lightbus' logging system needs a major refactoring, or perhaps completely tearing our and reimplementing. It was one of the first areas implemented and I've been papering over the cracks since then.
I've marked this as a 'good first issue', but the caveat being that you'll need a decent understanding of Python's logging system.
Existing problems
%). This means all messages must be formatted strings, regardless of whether the message will be logged or not. This impacts performance.Existing features (to keep)
I want the following (currently existing) features to also be present in the new system:
New features
Addendum
Having reviewing the logging code it actually doesn't look too bad. I'd be tempted to:
LBulletsintoLogListandLogMapping