Re: [Python-ideas] Alternative formatting styles for logging events in Python 3.3

On Fri, Feb 11, 2011 at 3:21 AM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Given that the ability to pass in something other than a %-formatting format string isn't even *mentioned* in the API documentation for logging.debug [1][2] this trick could definitely use some additional exposure. While this existing capability definitely makes the per-event part of my suggestion redundant, I think the per-logger part of it still has some merit. If loggers are defined as inheriting their formatting style from their parent loggers when an explicit style isn't provided, then an application or library that wants to use an alternate formatting style only needs to set it up once on their primary logger and away they go. (Creating the root logger with a formatting style other than '%' would obviously be a bad idea, so it may be worth issuing an explicit warning when someone does that) Cheers, Nick. [1] http://docs.python.org/dev/library/logging#logging.Logger.debug [2] http://docs.python.org/dev/library/logging#logging.debug -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Nick Coghlan <ncoghlan@...> writes:
I'll update the documentation soon. Of course you're not passing a str.format string directly to the logging call, but a BraceMessage style object. This usage is documented, but I agree a link from the logger.debug() etc. calls would be an improvement.
An application or library can still easily use the BraceMessage/DollarMessage approach which I outlined in my reply to your first post, which got to you but was bounced from python-ideas. This does not introduce the complication of handling the root logger's style, or what to do if a using application or logger in the same part of the hierarchy wants to use a different style (perhaps this could happen with namespace packages). Since my original reply got lost from python-ideas, I'll just reproduce it here:
From: Nick Coghlan <ncoghlan@gmail.com>
Actually, that's not the case. For example, the following script: #!/usr/bin/env python import logging class BraceMessage(object): def __init__(self, fmt, *args, **kwargs): self._fmt = fmt self._args = args self._kwargs = kwargs def __str__(self): return self._fmt.format(*self._args, **self._kwargs) _ = BraceMessage def main(): logger = logging.getLogger('fmttest') logger.debug(_('Message {verb} using {0}', 'braces', verb='formatted')) if __name__ == '__main__': root = logging.getLogger() root.addHandler(logging.StreamHandler()) root.setLevel(logging.DEBUG) main() works correctly today on Python 2.6, 2.7, 3.0, 3.1 and 3.2 to print Message formatted using braces as you might expect. Furthermore, the actual formatting is deferred or "lazy" (exactly as for %-formatting). Note that you could have also used a DollarMessage class which uses string.Template for formatting. Note that this allows flexible formatting at a per-call (rather than per-logger) level. The use of an alias for the class would make things more readable (I used _ just for convenience, and I'm of course aware of its usual aliasing to gettext, but a suitably brief alternative could be used instead). Note that DollarMessage/BraceMessage are described here http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.ht... and already available in the logutils package, see http://code.google.com/p/logutils/ and http://packages.python.org/logutils/whatsnew.html Perhaps this style could be emphasised in the stdlib documentation. The XXXMessage classes could be brought into stdlib (not something I'm particularly advocating, mind you). Regards, Vinay Sajip

Nick Coghlan <ncoghlan@...> writes:
I'll update the documentation soon. Of course you're not passing a str.format string directly to the logging call, but a BraceMessage style object. This usage is documented, but I agree a link from the logger.debug() etc. calls would be an improvement.
An application or library can still easily use the BraceMessage/DollarMessage approach which I outlined in my reply to your first post, which got to you but was bounced from python-ideas. This does not introduce the complication of handling the root logger's style, or what to do if a using application or logger in the same part of the hierarchy wants to use a different style (perhaps this could happen with namespace packages). Since my original reply got lost from python-ideas, I'll just reproduce it here:
From: Nick Coghlan <ncoghlan@gmail.com>
Actually, that's not the case. For example, the following script: #!/usr/bin/env python import logging class BraceMessage(object): def __init__(self, fmt, *args, **kwargs): self._fmt = fmt self._args = args self._kwargs = kwargs def __str__(self): return self._fmt.format(*self._args, **self._kwargs) _ = BraceMessage def main(): logger = logging.getLogger('fmttest') logger.debug(_('Message {verb} using {0}', 'braces', verb='formatted')) if __name__ == '__main__': root = logging.getLogger() root.addHandler(logging.StreamHandler()) root.setLevel(logging.DEBUG) main() works correctly today on Python 2.6, 2.7, 3.0, 3.1 and 3.2 to print Message formatted using braces as you might expect. Furthermore, the actual formatting is deferred or "lazy" (exactly as for %-formatting). Note that you could have also used a DollarMessage class which uses string.Template for formatting. Note that this allows flexible formatting at a per-call (rather than per-logger) level. The use of an alias for the class would make things more readable (I used _ just for convenience, and I'm of course aware of its usual aliasing to gettext, but a suitably brief alternative could be used instead). Note that DollarMessage/BraceMessage are described here http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.ht... and already available in the logutils package, see http://code.google.com/p/logutils/ and http://packages.python.org/logutils/whatsnew.html Perhaps this style could be emphasised in the stdlib documentation. The XXXMessage classes could be brought into stdlib (not something I'm particularly advocating, mind you). Regards, Vinay Sajip
participants (2)
-
Nick Coghlan
-
Vinay Sajip