8000 Termination and spaces · Issue #11 · xolox/python-coloredlogs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Termination and spaces #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
con-f-use opened this issue Dec 1, 2015 · 5 comments
Closed

Termination and spaces #11

con-f-use opened this issue Dec 1, 2015 · 5 comments

Comments

@con-f-use
Copy link

In the present version, colouring of the different fields (name, loglevel, hostname, etc.) seems to be dependent on placement of white spaces. I.e. if no white spaces are placed between fields, consecutive fields will have the colour of the first in string. Is that intended behaviour? It can be seen using the following code:

import coloredlogs, logging
from logging import debug, info, error, warning as warn
coloredlogs.install(level='DEBUG', fmt=formatstring, datefmt='%d.%m.%y %H:%M' )
debug("debug")
info("info")
warn("warn")
error("error")

where two different format strings are used (note the spaces around levelanme, name and process string formatters):

formatstring='[ %(levelname)-8s ] (%(asctime)s %(name)s @ %(hostname)s [%(process)d]'   # with spaces
formatstring='[%(levelname)-8s] (%(asctime)s %(name)s@%(hostname)s[%(process)d]'       # without spaces

The result is something like this (note the color of the levelname and the blurred hostname field):

with spaces
without spaces
@xolox
Copy link
Owner
xolox commented Dec 1, 2015

Yes this is intended behavior. The current approach is documented under the colorize_format() method. Basically I decided to implement it like this (the "simple" approach) until someone came up with a use case not covered by the simple approach. And here you are! :-)

So consider this a documented implementation detail. If we can find a way to improve this that doesn't break backwards compatibility (at least not in a surprising way) I'm open to changing the implementation.

@xolox
Copy link
Owner
xolox commented Dec 1, 2015

An advantage of the current simple approach (from my perspective) is that it's possible to highlight things like %(name)s[%(process)d] as a single logical unit with a single color that encompasses the [ and ] characters. It also helps that coloredlogs doesn't need to fully understand and (properly) parse the format of logging format strings.

Making the current behavior more flexible introduces more decisions to make. For example if the format string contains %(name)s[%(process)d] and styling has been specified for both name and process, what should the color of the [ and ] tokens be? Just leave them at the default color? That looks kind of weird, but maybe that's just me :-).

The following approach might work:

  1. We split the format string on whitespace resulting in a list of whitespace separated tokens.
  2. For each whitespace separated token the following decision process is followed:
    • If the token contains only one %(...) field with a color/style defined then the complete token is highlighted in that color/style (this provides compatibility with the current behavior).
    • If the token contains multiple %(...) fields with a color/style defined then each %(...) field is highlighted according to the configured color/style but any text in between is left as is.

This change in behavior requires real/proper parsing of logging format strings. This isn't impossible to do of course, but it might be a bit tricky to get it right :-). So one the one hand this complicates the library but on the other hand it can guarantee correct behavior (provided that the format string parsing and rewriting is correct of course). In contrast the current approach is kind of dumb but works fine most of the time (it's possible to break it though, I guess).

@con-f-use
Copy link
Author

Sounds good. Another approach would be to introduce a reset string, that ends the current colouring, or colour parenthesis strings respectively.

xolox added a commit that referenced this issue May 13, 2018
@xolox
Release 10.0: Proper format string parsing, support for style='{'
1cbf0c6 
This fixes #11 and #17.
@xolox xolox closed this as completed in 9082a12 May 13, 2018
@xolox
Copy link
Owner
xolox commented May 13, 2018

Hi again @con-f-use and sorry for the long silence here. I've just released coloredlogs 10.0 which should fix the issue you reported: coloredlogs is now finally able to properly distinguish formatting directives from their surrounding text, dropping the dependency on whitespace delimiters.

@ghost
Copy link
ghost commented Dec 14, 2021 •
edited by ghost
Loading

I'm still seeing a similar issue with coloredlogs 15.0.1. With fmt="{asctime} [{levelname[0]}] {name}: {message}", the trailing colon after the name field is colored as well. If I change it to fmt="{asctime} [{levelname[0]}] {name} : {message}", the colon is not colored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xolox @con-f-use
0