<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 30, 2011, at 9:57 PM, Tim Allen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Wed, Nov 30, 2011 at 01:04:27PM -0000, <a href="mailto:exarkun@twistedmatrix.com">exarkun@twistedmatrix.com</a> wrote:<br><blockquote type="cite">On 04:07 am, <a href="mailto:screwtape@froup.com">screwtape@froup.com</a> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">If the standard Twisted logging functions automatically constructed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LogMessage instances from dict instances, it should be easy enough for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">future ILogObserver implementations to do the right thing (by just<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">calling str(msg)). Of course, they could also do more sophisticated<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">things like pulling particular keys out of the message to set<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">observer-specific message properties (like syslog channel and severity,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">etc.)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Oooorrrr there could be a function that takes a dict intended to <br></blockquote><blockquote type="cite">represent a text message and returns that message as a string.<br></blockquote><br>As mentioned, we already have one of those in the form of<br>textFromEventDict().</div></blockquote><div><br></div><div>Right, I think that's the tone all those extra letters are meant to suggest :).</div><br><blockquote type="cite"><div>The trouble is that everybody who writes<br>a LogObserver needs to know that it exists, and remember to call it. If<br>it were the __str__() method of a LogMessage object, they'd have to go<br>out of their way to *not* do the right thing.<br></div></blockquote></div><br><div>I really don't like using __str__ for structured conversions. For example, textFromEventDict has very strict error-handling behavior: it will try as hard as it can to give you <i>something</i> so that you don't need to do extra error handling in your log observer. But if you can get instances of LogMessage or some derived message type or possibly application-derived message types, the behavior might change and the error-handling would be less strict and now the default log observers need to be double-careful; once in LogMessage.__str__, once in the thing that calls it because you can never really know what str(x) is going to do.</div><div><br></div><div>For another there's a whole nasty battery of unicode-or-bytes issues that crop up when you start using __str__.</div><div><br></div><div>Finally, and I'm leaving it for last because this concern is rather silly, right now log events are constructed and propagated with extremely little copying, and the copying that does happen (ahem, log contexts) needs to be reduced. Adding a LogMessage object into the mix, even if it is a subclass of dict, means we have to, at the very least, copy all the values from msg()'s keyword arguments into a new object, rather than just propagating them to log observers.</div><div><br></div><div>-glyph</div></body></html>