This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: threading.Timer class: Continue periodical execution till action returns True
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: pitrou Nosy List: cheryl.sabella, pitrou, rhettinger, slytomcat, tim.peters
Priority: normal Keywords:

Created on 2017-02-15 14:54 by slytomcat, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 191 closed slytomcat, 2017-02-20 09:44
Messages (6)
msg287858 - (view) Author: (slytomcat) * Date: 2017-02-15 14:54
I think that functionality of threading.Timer class can be easily extended to generate the sequence of runs with specified period. The idea comes from the GLib.timeout_add function. 

Run method of threading.Timer should look like:

    def run(self):
        """Continue execution after wait till function returns True"""
        while(not self.finished.wait(self.interval)):
            if not self.function(*self.args, **self.kwargs):
                break
        self.finished.set()
msg288398 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-02-23 03:14
Ideally, proposed API expansions should be based on a demonstrated user need. This API is over decade old and I don't recall a single user request for this functionality.  A quick scan of StackOverflow didn't turn-up any questions or answers on the subject.

I don't see anything intrinsically wrong with the idea, but in the absence of demonstrated need, it is likely to become unused cruft with it attendant burden on maintenance and cognitive load.
msg291155 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-04-05 05:37
Antoine, do you care to make the call on this one?
msg291163 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-04-05 06:54
This will obviously break some existing code which passes a function returning true to Timer.  I concur with Raymond: I don't think this is a good idea.  Also, the Timer class itself is a rather simplistic answer to the problem of scheduling callbacks in the future (it uses a dedicated thread per callback, which is extremely wasteful).  You'll find better solutions in more modern toolkits, such as asyncio; or you can easily write your own logic yourself.
msg295251 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-06-06 11:28
This bug report has been closed, but the PR is still open.  Please close the PR.  Thank you.
msg295263 - (view) Author: (slytomcat) * Date: 2017-06-06 14:23
done

2017-06-06 14:28 GMT+03:00 Cheryl Sabella <report@bugs.python.org>:

>
> Cheryl Sabella added the comment:
>
> This bug report has been closed, but the PR is still open.  Please close
> the PR.  Thank you.
>
> ----------
> nosy: +csabella
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue29569>
> _______________________________________
>
History
Date User Action Args
2022-04-11 14:58:43adminsetgithub: 73755
2017-06-06 14:23:23slytomcatsetmessages: + msg295263
2017-06-06 11:28:01cheryl.sabellasetnosy: + cheryl.sabella
messages: + msg295251
2017-04-05 15:27:34rhettingersetstatus: open -> closed
resolution: rejected
stage: resolved
2017-04-05 06:54:17pitrousetnosy: + tim.peters
messages: + msg291163
2017-04-05 05:37:14rhettingersetassignee: pitrou

messages: + msg291155
nosy: + pitrou
2017-02-23 03:14:54rhettingersetnosy: + rhettinger
messages: + msg288398
2017-02-20 11:32:53slytomcatsetpull_requests: - pull_request81
2017-02-20 09:44:36slytomcatsetpull_requests: + pull_request157
2017-02-15 15:01:15slytomcatsetpull_requests: + pull_request81
2017-02-15 14:54:10slytomcatcreate