[systemd-devel] python - reading the journal

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Wed Feb 6 13:34:34 PST 2013

On Tue, Feb 05, 2013 at 11:25:47AM -0800, David Strauss wrote:
> On Mon, Feb 4, 2013 at 6:49 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > What about renaming Journalctl to Journal? It doesn't really control anything :)
> Neither does the actual journalctl. :-)

> But, systemd's naming convention is to call first-tier shell utilities
> <something>ctl and second-tier shell utilities systemd-<something>ctl.
> It should definitely not be in the Python library.
> I prefer to have the first layer of C wrappers mimic the original C
> API as closely as possible (in function names and arguments) and have
> a regular Python wrapper providing an OO-friendly, Pythonic interface.
> It keeps the C minimal and opens the door to alternative Pythonic
> abstractions without forcing the authors to write their own C module.
Oh, I think that in this case the Python API is very minimal and closely
mirrors the C API. Main difference is that in C all journal functions
take sd_journal* as first argument, and in the proposed module,
those functions become methods on the Journal[ctl] object. I think that
this change is more or less required, unless we would want to expose
sd_journal* to Python code. I'm pretty sure that this would be a bad
idea, and wouldn't actually provide any aditional flexibility.

sd_journal_seek_head(j) -> j.seek_head()
sd_journal_seek_tail(j) -> j.seek_tail()
sd_journal_seek_monotonic_usec(j, boot_id, usec) -> j.seek_monotonic(usec, boot_id)

The only non-trivial transformation is the call_dict. But
(a) you can avoid it by passing call_dict={},
(b) it seems very reasonable to have something like that. Otherwise
pretty much all code would be doing similar transformations.

I think that this module provides a usable interface, and can be used
as a basis for more complicated interfaces if necessary. Of course
improvments can be definitely made, e.g. I think that not the whole
API is currently covered.


More information about the systemd-devel mailing list