All of lore.kernel.org
 help / color / mirror / Atom feed
From: andy.shevchenko@gmail.com
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>,
	linux-gpio@vger.kernel.org
Subject: Re: [libgpiod] [RFC PATCH] bindings: python: allow specifying infinite timeout
Date: Tue, 23 May 2023 15:18:50 +0300	[thread overview]
Message-ID: <ZGyvKn4NG0j9K2Q_@surfacebook> (raw)
In-Reply-To: <CAMRc=McrerNizhJ+d1m6PaDf65UX-RrZjAYjdABiLjZ69TPRWA@mail.gmail.com>

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@gmail.com> 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?

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-05-23 12:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19 17:46 [libgpiod] [RFC PATCH] bindings: python: allow specifying infinite timeout Nicolas Frattaroli
2023-05-23 10:06 ` Bartosz Golaszewski
2023-05-23 12:18   ` andy.shevchenko [this message]
2023-05-23 12:33     ` Bartosz Golaszewski
2023-05-23 12:38       ` Nicolas Frattaroli
2023-05-23 13:04         ` Bartosz Golaszewski
2023-05-23 13:18           ` Nicolas Frattaroli
2023-05-23 13:27             ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZGyvKn4NG0j9K2Q_@surfacebook \
    --to=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=frattaroli.nicolas@gmail.com \
    --cc=linux-gpio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.