On Sat, Jun 15, 2013 at 9:38 PM, Glyph <glyph@twistedmatrix.com> wrote:

On Jun 15, 2013, at 9:17 AM, Christopher Armstrong <radix@twistedmatrix.com> wrote:

I think I would just want one more feature:

Logger().emit(dudelog.LogLevel.warn, a="hi")

Right now, this doesn't spit out anything into my log file, with
default observers. I want it to emit some simple representation of the
keys and values.

On the other hand, the same is true of log.msg(a="hi"), but maybe this
should be implemented (somehow) in Logger() codepath to avoid breaking

I keep going back and forth on this.

On the one hand, the main thing I want to do is to just say "if you want your message to appear in the log file, let's just implement a structured log file and you can read it from there.  If you have no human-readable format string to explain your message, clearly you didn't intend for a human to read it."

On the other hand, we already implement log filtering, so filtering the message out of the log based on the absence of the format string is a little overloaded.  And we should really be encouraging people to populate messages with useful structured data.

(I was going to say that without a format string I couldn't have my stand-in UUID feature, but then I realized that namespace + set of keys is probably good enough to generate that too, so never mind.  Also it seems like I'm the only one who likes that feature so maybe it doesn't matter!)

How would you feel about a special token that you have to pass explicitly?

Logger().warn(ALL_KEYS, a="hi")

I'm not wild about the need for an extra constant I'd have to import, but I'd like to understand why you think the arbitrary keys shouldn't be included in the message. Can you elaborate on why?

Christopher Armstrong