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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, Jun 10, 2022 at 6:23 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> 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()?;
>

So in Python you'd like to see an equivalent in the form of:

req = gpiod.request_lines(chip="/dev/gpiochip0", lines=["GPIO17",
"RESET_0"], edge_detection=Edge.BOTH)

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

and:

for event in req.read_edge_events():
    print(event)

Note that for the event reading: implementing yield in C API is not
currently possible. I think the best way to implement the above
example is to simply return a buffer filled with events that is
already iterable.

Ok I can work with that. It also makes sense to take keyword arguments
by default in all methods.

Thanks
Bart

>
> 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.