On Wed, Oct 12, 2022 at 02:34:44PM +0200, Bartosz Golaszewski wrote: > On Fri, Oct 7, 2022 at 4:55 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > This is the third iteration of python bindings for libgpiod but it really has > > very little in common with the previous version. > > > > This time the code has been split into high-level python and low-level > > C layers with the latter only doing the bare minimum. > > > > The data model is mostly based on the C++ one with the main difference > > being utilizing dynamic typing and keyword arguments in place of the > > builder pattern. That allows us to reduce the number of methods and > > objects. > > > > Because python doesn't have RAII, unlike C++, we provide a module-level > > request_lines() helper as gpiod.Chip(path).request_lines(...) one-liner > > could lead to the chip left dangling even after the last reference is > > dropped. > > > > Because python forces us to dynamically allocate objects all the time even > > for fundamental types (which are also immutable) there's no point in trying > > to replicate the edge-event buffer. Instead LineRequest.read_edge_event() > > just returns a list of events. > > > > Bartosz Golaszewski (4): > > > > I fixed the one nit from Andy. If there are no objections I'd like to > apply this and squash the entire v2 patch series into one big commit > and apply it to the master branch. This way we can stop keeping this > temporary branch and continue the development (tools, rust, possible > further tweaks to the API) on master. > I'm in the process of reviewing, so hold off for a bit if you can. If not, at the very least IIIIpdII -> IIIIpkII in patch 4. Otherwise you get this on 32 bit platforms: $ gpioget.py /dev/gpiochip0 17 *** stack smashing detected ***: terminated Cheers, Kent.