this simple code:
"
import gtk
from threading import Timer
from time import sleep

def p():
    print "p"

Timer(1, p).start()

#gtk.main()
sleep(10)
print "done"
does print "p" a second after it starts.
when I remove the comment of the gtk.main() line: the "p" is never printed.

It is very exposed, as Timer is a common tool to build a GUI therefore
with the gtk.main() loop active.

It is probably a problem with the gtk/gobject Python binding.
By the way, you're supposed to call `gobject.threads_init()` if you use
threads with Python and gobject/gtk.
Besides, gtk certainly has its own timing facilities, while
threading.Timer is rather crude.

OK, this is a workaround. 

adding this line 
gtk.gdk.threads_init()

makes the job. And that's ok for me.

nevertheless, I still got the feeling that's this is a flaw in the Timer
implementation: it's behaviour is changed by some external (gtk) code.

Well I'm not a gtk user, but try to do something else than a "print" in
the timer. Perhaps gtk redirects all standard IO or something. It sounds
very strange that threads would stop working when gtk is imported.

pygtk doesn't release the GIL around its internal calls unless you call
threads_init.  So I think this is pretty clearly just a misuse of the
pygtk library.  There's nothing at all Python can do about it.  If an
extension library doesn't release the GIL, no Python code can run
concurrently with it.  In this case, the extension API you've invoked is
the Gtk main loop, which runs until you stop it, usually right before
your gtk app exits.

When using gtk and threads, it's necessary to call
   gtk.gdk.threads_init()