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 am really, really puzzled by this reaction. I am wondering if you read my message carefully, or if I didn't express myself well.
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.
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.
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.
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.
Does this explanation make you feel less worried about the inclusion of such a feature?
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.*")
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.
So: again, you can get what you want exactly and ignore the other stuff.
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.
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.