So the threading module has a Timer class inhereted from Thread class to repeatedly execute some tasks.
I was wondering why doesn't the multiprocessing module have something like an analogous TimedProcess class for e.g., which is inhereted from Process to repeatedly execute some tasks?
It is possible to write such a timed process and I have written one but still curious. Or am I missing something?
It's pretty straightforward to implement yourself:
from multiprocessing import Process, Event
class Timer(Process):
def __init__(self, interval, function, args=[], kwargs={}):
super(Timer, self).__init__()
self.interval = interval
self.function = function
self.args = args
self.kwargs = kwargs
self.finished = Event()
def cancel(self):
"""Stop the timer if it hasn't finished yet"""
self.finished.set()
def run(self):
self.finished.wait(self.interval)
if not self.finished.is_set():
self.function(*self.args, **self.kwargs)
self.finished.set()
I'm not sure why there isn't one included in the stdlib. Perhaps because its less likely to be useful?
This is a pretty open-ended question, and the literal answer wouldn't be very useful.
But let's try to come up with some educated guesses.
pyprocessing* didn't have it. Why not? Probably because it's not particularly useful.
Almost any non-trivial app that needs timers needs multiple timers, recurring timers, relatively fast timers, etc. Firing off a new thread for each timed event is a terrible idea.
So, why is it even in threading?
Well, for trivial apps, it can actually be useful. It's not that unreasonable to add threading to a single-process app just so you can kick off a Timer to signal the main thread and interrupt it if it gets lost, for example. But that's not relevant to multiprocessing.
Also, threading is one of those modules that's designed to be useful as example code, not just as a library—and that was especially true when it was first added. That's why the docs link to the source. And Timer is a great piece of sample code—it's obvious to what it does and how it works, and it's hard to think of anything much simpler that could demonstrate how to use a synchronization object. But you don't need the code in two places to serve as an example, and there's nothing additional and multiprocessing-specific to demonstrate.
And finally Itamar Shtull-Trauring wanted it, did the work, and offered it, and nobody had any good argument against including it; presumably the same thing never happened with pyprocessing.**
During the 2.6/3.0 planning, PEP 371 adapted pyprocessing into the stdlib multiprocessing module. This was a pretty big job, and done in a bit of a rush, especially since they took on the task of PEP8-ifying the names in threading so they wouldn't have to rename all of pyprocessing to match the non-standard names in threading just for someone to rename them all again when threading got fixed a year or two later. So, even though being a drop-in replacement for threading whenever possible was one of the secondary goals, I'm guessing nobody did a complete survey to make sure that was accomplished.
Since then, presumably, either nobody has noticed it was missing and suggested it, or nobody has made a compelling enough argument, or nobody did the actual work. If you believe it should be added, and can defend your belief, create a bug or write to python-ideas, and include your implementation, and sign a PSF contributor's agreement, and it may get you immortalized. :)
* Unfortunately, I can't find any good historical links to pyprocessing. The source repo is dead, the contributors moved on to maintaining the stdlib multiprocessing module and the PyPI multiprocessing backport, even that project has largely been supplanted by billiard, and in the intervening years a new and unrelated project has taken over the original name…
** Note that in issue #428326, where Timer was first suggested, more than half of the rationale is that it's good example code.
