I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. 

Here is a patch that adds such a class to the threading module. You then use it like this:

import threading

def hello():
    print "Hi there!"

t = threading.PeriodicTimer(5, hello)
t.start()    # "Hi there!" will be printed every five seconds.

The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy.

Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results.

I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless.  

"Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results."

I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so.

I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)

Here is finished patch. It includes both documentation and a few unit tests.
File Added: add-PeriodicTimer-2.patch

"I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)"

Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :)

Why not subclass threading._Thread and override just the run method? It would make more sense, then, to stick with the "cancel" method name instead of "end".

There is no threading._Thread class.

Sorry about that; I meant threading._Timer.

Pretty pointless I think, the semantics for the two classes are totally different. The method is named end() because it has a very different meaning than the Timer class' cancel().

msg52115 "Looks fine to me".  The code change is small, the rest of the patch is doc changes or unit tests, could someone run with this?

Could someone with commit privileges please take a look at the patch, thanks.

I don't really agree with "negative periods behave like if the period was 0". Negative periods don't mean anything and should just raise ValueError.
(as for 0, well, we can allow it anyway, although it means the timer just degenerates into an busy loop)

The doc will have to be converted to the new Sphinx format, as well.

Java's Timer class tends to be discouraged these days in favor of ScheduledExecutorService.scheduleAtFixedRate and .scheduleWithFixedDelay (http://download.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html). Could you say why you modeled this interface off of java.util.Timer instead of ScheduledExecutor? See http://www.python.org/dev/peps/pep-3148/ for the basis of executors in Python.

I'm skeptical of having a PeriodicTimer that embeds a fixed-delay timing. Both fixed-rate and fixed-delay are useful for different things, and given the ambiguity we probably shouldn't give in to the temptation to guess. 

I'm skeptical of having a new thread per periodic task. It's a little more work to multiplex tasks onto shared threads, and maybe that work isn't worth it for now, but I think the interface should allow future implementations to multiplex their tasks.