El pri­mer ca­so es así:

# llamar f() en 3 segundos
QTimer.singleShot(3000, f)

El se­gun­do es así:

# Creamos un QTimer
timer = QTimer()
# Lo conectamos a f
timer.timeout.connect(f)
# Llamamos a f() cada 5 segundos
timer.start(5000)

¿Fá­ci­l, no? Bue­no, sí, pe­ro tie­ne un par de tram­pa­s.

1. Hay que guar­dar la re­fe­ren­cia a ti­mer

   Si no, lo re­­co­­­ge el ba­­su­­re­­ro, y nun­­ca se lla­­ma a f()

2. Ca­­paz que son más de 5 se­­gun­­dos

   Va a lla­mar a f() más o me­nos ca­da 5 se­gun­dos des­pués de que en­tre al event lo­op. Tal vez eso no sea en­se­gui­da des­pués de que arran­cás el ti­me­r!

3. Ca­­paz que se pi­san las lla­­ma­­das

   Si f() tar­da mu­cho en ter­mi­na­r, y vuel­ve a en­trar al event lo­op (por ejem­plo, lla­man­do a pro­ce­ssE­ven­ts) tal vez ti­mer se dis­pa­re an­tes que f() ter­mi­ne, y la lla­me de nue­vo. Eso ca­si nun­ca es bue­na idea.

Una al­ter­na­ti­va:

def f():
    try:
        # Hacé cosas
    finally:
        QTimer.singleShot(5000, f)

f()

Ese fragmento llama a f() una sola vez, pero ella misma se pone en cola para correr en 5 segundos. Ya que lo hace en un finally lo va a hacer aún si las cosas se rompen.

O sea, no se va a pisar. También quiere decir que no son 5 segundos, sino 5 más lo que tarde f. Y no hace falta guardar referencias al QTimer.

Úl­ti­mo ti­po: po­dés usar QTi­mer pa­ra que al­go se ha­ga "a­pe­nas es­tés en el event lo­op"

QTimer.singleShot(0, f)

¡O­ja­lá sir­va!