[systemd-devel] python - reading the journal

[David Strauss]

On Mon, Feb 18, 2013 at 11:28 AM, Steven Hiscocks
<steven-systemd at hiscocks.me.uk> wrote:
> Sounds good. I suppose `log_level` should become `add_loglevel_matches` for
> consistency. (or actually `add_priority_matches`?)

"Log level" is the Pythonic language; please continue using it. The
journal itself may even move to it because "priority" is
counter-intuitive.

> I was missing the default value of None in `this_machine`. It's supposed to
> be used: "myjournal.this_machine()" (or "myjournal.add_machine_match()" with
> above changes). Alternatively, the default None could be removed , and
> constants set `CURRENT_MACHINE=id128.get_machine()`, etc., which then should
> be used when calling the method?

That sounds even better. Presumably, id128.get_machine() is not too
heavy to call once each time the logging code gets imported?

The ultimate would be CURRENT_MACHINE=<something-constant> and a
function that lazy-loads id128.get_machine() on the first request. It
may be a premature optimization for performance, but it's nice to be
able to import a Python module without worrying about it throwing an
exception initializing its constants.

> I'll add this to the documentation, but I think `get_next` should stay, as
> it compliments `get_previous` and use of the `skip` value.

Makes sense.

> Sure. I'll put in `UnicodeDecodeError`. I'm undecided on whether the call of
> `self.converters[key](value)` exception handling should be limited to
> `KeyError`? This would mean that the whole log entry would fail to return if
> one of the converters failed.

Even a set of explicit exception classes is okay. Something that's a
complete surprise will still bubble up.

--
David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]