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