Re: [libgpiod] [RFC PATCH] bindings: python: allow specifying infinite timeout

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Tue, May 23, 2023 at 2:38 PM Nicolas Frattaroli
<frattaroli.nicolas@xxxxxxxxx> wrote:
>
> On Dienstag, 23. Mai 2023 14:33:12 CEST Bartosz Golaszewski wrote:
> > On Tue, May 23, 2023 at 2:18 PM <andy.shevchenko@xxxxxxxxx> wrote:
> > >
> > > Tue, May 23, 2023 at 12:06:47PM +0200, Bartosz Golaszewski kirjoitti:
> > > > On Fri, May 19, 2023 at 7:47 PM Nicolas Frattaroli
> > > > <frattaroli.nicolas@xxxxxxxxx> wrote:
> > >
> > > > > So far, libgpiod's Python bindings had no way to state that a
> > > > > user wishes to wait for events indefinitely, as a timeout of
> > > > > None would intentionally be converted to 0 seconds, i.e. return
> > > > > from the select call in poll_fd immediately.
> > > > >
> > > > > The usual Python convention and even the select convention is
> > > > > to block indefinitely on a timeout=None. However, changing the
> > > > > poll_fd function to do this now would change an (intentional)
> > > > > API design choice by libgpiod 2.0 that API users presumably
> > > > > rely on.
> > > > >
> > > > > By allowing float("inf") (or in fact math.inf, or your favourite
> > > > > other way to get an infinite float) to mean waiting infinitely
> > > > > solves this by extending the API rather than changing it.
> > > > >
> > > > > On gpiod Python bindings without this change, passing inf results
> > > > > in an OverflowError being raised in select. API users who wish to
> > > > > support older versions of the bindings can catch this exception and
> > > > > act on it.
> > >
> > > ...
> > >
> > > > I like this approach too. In fact - it may be even clearer and more
> > > > intuitive than converting None to infinite timeout.
> > >
> > > With all respect to the clever design solutions I would rather go the
> > > de facto Pythonic way. If the native libraries use None for indefinite
> > > then it's better to do that way, otherwise we will add quite a confusion
> > > to the Python users.
> > >
> > > > Any objections against using negative numbers for the same purpose as well?
> > >
> > > The question here is: What in the very same situations are other (presumably
> > > native) Python libraries using?
> > >
> >
> > As has been said elsewhere - the pythonic way is to interpret None as
> > indefinite timeout. It's just that it would change the current
> > behavior. The question is - should we interpret the current behavior
> > as "undefined" and change it, or "defined but not documented" and
> > consider it part of the API.
> >
> > Bart
> >
>
> As an alternate suggestion, we could change the default function argument
> to 0.0 and remove the None -> 0 code. That way, people who were calling
> the function with no arguments still get the same behaviour, and the
> only break is for users who explicitly passed None.
>

Honestly, if we were to change the behavior, then I'd prefer to do it
right and not use any half-measures.

Bart