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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox