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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

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