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

[Nicolas Frattaroli <frattaroli.nicolas@xxxxxxxxx>]

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.

Kind regards,
Nicolas Frattaroli