<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 15, 2013, at 3:55 AM, Phil Mayers <<a href="mailto:p.mayers@imperial.ac.uk">p.mayers@imperial.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 06/15/2013 06:48 AM, Christopher Armstrong wrote:<br><br><blockquote type="cite">There's... a lot here. I'm overwhelmed by how complex this system<br>would be, and I think that end users would be as well. I don't really<br>want to put UUIDs into my source code, whether I type them or paste<br>them, and I don't want to have to invoke command line tools to figure<br>out what those UUIDs in order to be a good developer.<br></blockquote><br>+1. I like the general idea of better logging via keyword args and an "id", but I strongly dislike the idea of using UUIDs as log message identifiers.<br><br>In fact, I'll go so far as to say I defintely wouldn't use such a system, and for Twisted to migrate to it would actually reduce the utility of the in-built logging, because I'd have to build and maintain something to translate Twisted log messages I cared about into whatever system I built to do my own logging :o(<br></div></blockquote><div dir="auto"><br></div><div dir="auto">I am really, really puzzled by this reaction. I am wondering if you read my message carefully, or if I didn't express myself well.</div><div dir="auto"><br></div><div dir="auto">If I were to implement the system that I have proposed, you could completely ignore it. You could never deal with a UUID ever, and process logs based on whatever other attributes you like. There's nothing to translate. Unless when you say "translate" you mean translating the UUID of a currently ad-hoc message (one which doesn't specify or document its own unique attributes) which is something that would just be impossible without this feature.</div><div dir="auto"><br></div><div dir="auto">The only overhead that you'd ever incur would be a single call per log event - probably per-process-lifetime, since the result could be cached - to uuid.uuid5, which is not exactly the most expensive function. It would be called internally though; you wouldn't have to call it yourself or be aware that it was being called.</div><div dir="auto"><br></div><div dir="auto">If you had the use-case that I believe many people do - which is to evolve a stable identifier for a previously ad-hoc log message - then you could do that. Otherwise this wouldn't affect you.</div><div dir="auto"><br></div><div dir="auto">What I've proposed with UUIDs is to identify *specific semantic events* that you might want to do monitoring/alerting on, which may move between systems.</div><div dir="auto"><br></div><div dir="auto">Does this explanation make you feel less worried about the inclusion of such a feature?</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">I think there's basically no practical benefit over the hierarchical<br>"system" + event-identifier system, where:<br></blockquote><br>+1. Hierarchial IDs also permit prefix-based wildcarding:<br><br>log.observe("twisted.factory.*")<br>log.exclude("twisted.factory.http.*")<br>log.observe("myapp.thing")<br>log.observe("txSomeProject.event.*")<br></div></blockquote><div><br></div><div>This is already implemented in <<a href="http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py">http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py</a>>; see for example setLogLevelForNamespace() <<a href="http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py#L175">http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py#L175</a>>.</div><div><br></div><div>Namespaces are just python module names by default, but nothing requires that; the only requirement is that they're strings separated with dots. You can instantiate a Logger object with whatever 'namespace' argument you want.</div><div><br></div><div>So: again, you can get what you want exactly and ignore the other stuff.</div><div><br></div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">1. it's trivial to specify a hierarchical, easy-to-read "system" key<br>that has a small-ish scope<br>2. you think of a unique event name in that small-ish scope and type it out.<br><br>I'm beginning to think #1 is the most important of all, but I think<br>I'll continue to use event-names to describe all my log statements.<br></blockquote><br>I pretty much agree with all of this.<br></div></blockquote><br></div><div>I am still not seeing the utility of one of these identifiers beyond class/method name, but you can always just pass the namespace explicitly.</div><div><br></div><div>-glyph</div></body></html>