On Jun 15, 2013, at 3:55 AM, Phil Mayers <p.may...@imperial.ac.uk> wrote:
> 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.*")
This is already implemented in
<http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py>;
see for example setLogLevelForNamespace()
<http://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/log.py#L175>.
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.
-glyph_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
