Vinay Sajip wrote:
For point 5, I'm not sure how best to handle Unicode support, so I'm canvassing suggestions. The API allows overriding of the message formatting logic at various stages - LogRecord, Handler or Formatter. This makes it fairly easy to provide arbitrary custom logic for Unicode encoding, etc. The change I've made allows for simple default processing - a "defaultEncoding" attribute defaulted to "latin_1" has been added to logging.
You should use sys.getdefaultencoding() for this. Python's default encoding is "ascii", BTW, not "latin-1".
Currently, the message format string is determined via LogRecord.getMessage(), which does a str() on the passed in message argument passed to the logging call. Under the proposed change:
- If the running Python has no Unicode support, the system does a str(), as it does currently. - If the message argument is not a Unicode string, the system does a str(), as it does currently. - If the message argument is a Unicode string (type(msg) == types.UnicodeType), the system does a msg.encode(defaultEncoding).
Perhaps there's some other reason, but why do you apply special treatment to Unicode ? Unicode objects behave pretty much the same as strings do, so the special casing doesn't seem necessary. I'd only do the str() call on objects which are not string types.
The resulting string is treated as the format string and the % operator applied with the arguments to obtain the final message string.
-- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Feb 15 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 45 days left EuroPython 2003, Charleroi, Belgium: 129 days left