threading.Timer class: Continue periodical execution till action returns True

[34349917-2616-4cf4-b7c9-4bda2f98b87a]

BPO	29569
Nosy	@tim-one, @rhettinger, @pitrou, @slytomcat, @csabella
PRs	python/cpython#191

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/pitrou' closed_at = created_at = labels = ['3.7', 'type-feature', 'library'] title = 'threading.Timer class: Continue periodical execution till action returns True' updated_at = user = 'https://github.com/slytomcat' ``` bugs.python.org fields: ```python activity = actor = 'slytomcat' assignee = 'pitrou' closed = True closed_date = closer = 'rhettinger' components = ['Library (Lib)'] creation = creator = 'slytomcat' dependencies = [] files = [] hgrepos = [] issue_num = 29569 keywords = [] message_count = 6.0 messages = ['287858', '288398', '291155', '291163', '295251', '295263'] nosy_count = 5.0 nosy_names = ['tim.peters', 'rhettinger', 'pitrou', 'slytomcat', 'cheryl.sabella'] pr_nums = ['191'] priority = 'normal' resolution = 'rejected' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue29569' versions = ['Python 3.7'] ```

[34349917-2616-4cf4-b7c9-4bda2f98b87a]

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()

[rhettinger]

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.

[rhettinger]

Antoine, do you care to make the call on this one?

[pitrou]

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.

[csabella]

This bug report has been closed, but the PR is still open. Please close the PR. Thank you.

[34349917-2616-4cf4-b7c9-4bda2f98b87a]

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\

---