On 06/15/2013 06:48 AM, Christopher Armstrong wrote:
There's... a lot here. I'm overwhelmed by how complex this system would be, and I think that end users would be as well. I don't really want to put UUIDs into my source code, whether I type them or paste them, and I don't want to have to invoke command line tools to figure out what those UUIDs in order to be a good developer.
+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. 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(
I think there's basically no practical benefit over the hierarchical "system" + event-identifier system, where:
+1. Hierarchial IDs also permit prefix-based wildcarding: log.observe("twisted.factory.*") log.exclude("twisted.factory.http.*") log.observe("myapp.thing") log.observe("txSomeProject.event.*") Obviously this is just an example; I haven't put any real thought into it.
1. it's trivial to specify a hierarchical, easy-to-read "system" key that has a small-ish scope 2. you think of a unique event name in that small-ish scope and type it out.
I'm beginning to think #1 is the most important of all, but I think I'll continue to use event-names to describe all my log statements.
I pretty much agree with all of this.