Re: [libgpiod v2][PATCH 3/5] bindings: python: add examples for v2 API

[Kent Gibson <warthog618@xxxxxxxxx>]

On Thu, Jun 09, 2022 at 06:06:04PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jun 9, 2022 at 3:21 PM Jiri Benc <jbenc@xxxxxxx> wrote:
> >
> > On Thu, 9 Jun 2022 10:42:44 +0200, Bartosz Golaszewski wrote:
> > > On Thu, Jun 9, 2022 at 6:49 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > > Agree that it would be easier to write a pythonic wrapper around the C
> > > > API in Python, so no problem with that.
> > > > However, the pythonic wrapper should the one named gpiod, as it is
> > > > intended to be the primary interface for Python.  Rename your existing
> > > > to gpiod_c or gpiod_core or something.
> > >
> > > I don't agree. The module that wraps the C library should still be
> > > called gpiod and be the primary interface. The pythonic module would
> > > just offer helpers that would still use the gpiod data types for most
> > > part.
> >
> > As a Python user, I'd much rather see the high level API being the
> > primary interface and being named 'gpiod'. The easier to use and more
> > Pythonic, the better. The low level library bindings and low level data
> > types are just an implementation detail for me when coding in Python.
> > If I wanted low level, I'd code everything directly in C.
> >
> 
> But Kent is not talking about a whole new "pythonic" layer on top of
> the code that is the subject of this series. The bindings are already
> quite pythonic in that you can get most stuff done with a "logical"
> one-liner. The gpiod module doesn't map C API 1:1, it already
> simplifies a bunch of interfaces. Kent's idea IIUC is about providing
> a set of helpers that would produce the gpiod objects in shorter code
> by hiding the details of intermediate objects being created.
> 

Yeah, no, I'm saying that there should be one primary Python interface
to gpiod, and it should be the most pythonic.  And complete.
The casual user should be able to get by with a few simple commands, but
the complete functionality should still be accessible, via that same
API, for more complicated cases.

> Re the event buffer: yeah, I think in python (unlike C++ or future
> Rust bindings) it makes sense to hide it within the request as we
> can't profit from implicitly not copying the event objects.
> 

That is a consequence of building on top of the gpiod C API, as you have
to deal with two object models, and the related type conversions or
lifecycle management.
A native binding built on top of the ioctls can use native objects
throughout can take better advantage of the language.
e.g. here the equivalent of my Python suggestion using my Rust
gpiocdev library (sadly without named lines support as I hadn't
considered that at the time):

    // request the lines
    let req = Request::builder()
        .on_chip("/dev/gpiochip0")
        .with_lines(&[17,18])
        .with_edge_detection(EdgeDetection::BothEdges)
        .request()?;

    // wait for line edge events
    for event in req.edge_events()? {
        println!("{:?}", event?);
    }

That has a hidden event buffer within the request.  The default size is 1,
but add .with_user_event_buffer_size(N) and you get an N event buffer.
There is no copying involved, just borrowing, as all the objects are
visible to the borrow checker.

> If anyone wants to create an even simpler, complete interface for
> gpiod, then it's a task for a whole new project. Think: pydbus built
> on top of GLib dbus bindings in python, built on top of glib's dbus
> implementation.
> 

Don't tempt me - though I would target the GPIO uAPI ioctls, not gpiod,
for the reasons above.

Cheers,
Kent.