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.