All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: andy.shevchenko@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:46 +0200	[thread overview]
Message-ID: <3608182.x0L4EvOPPF@archbook> (raw)
In-Reply-To: <CAMRc=Md3o9a9qrrPAugBo4tr15ciXRt-6EMSsMqZYA-JdkkqNA@mail.gmail.com>

On Dienstag, 23. Mai 2023 15:04:54 CEST Bartosz Golaszewski wrote:
> On Tue, May 23, 2023 at 2:38 PM Nicolas Frattaroli
> <frattaroli.nicolas@gmail.com> wrote:
> >
> > On Dienstag, 23. Mai 2023 14:33:12 CEST Bartosz Golaszewski wrote:
> > >
> > > ...
> > >
> > > 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
> 

That's fair, I don't mind either way. I don't think the behavioural
change would be that big of an issue either way; the obviousness of a
wait on events function that returns immediately by default is
debatable in my eyes, as the only use for using it like that I could
ever come up with is to peek at whether there are any events queued
up based on its return value.

What I do think is a bad solution now is the float("inf") stuff.
While it's fun to assign meaning to special floating point values,
I think it strictly makes the API worse for the sake of stability.

Kind regards,
Nicolas Frattaroli



  reply	other threads:[~2023-05-23 13:18 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
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 [this message]
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=3608182.x0L4EvOPPF@archbook \
    --to=frattaroli.nicolas@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --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.