Peter, First things first: For some reason I see your message coming in empty, but with two attachments. An "att*.txt" one with the actual message contents, and a "signature.asc". Makes it kind of hard to read ...
> No. There are many reasons why sleep() might return after t Not /that/ many, but true. But do you think that adding all of those if-when-but reasons to the issue I tried to explain would be a good idea ? I don't. I would just drown the actual issue with it. :-\ > No, because you get the actual time at some time between the the > previous and the next sleep No, you don't. Thats the whole trick. The only place where you ask for the time (and subtract it from the desired one) is directly infront of actually doing the sleep. (dotting i's works two ways I'm afraid :-) ). And the /asked for/ time (before subtraction of the current time I mean - ghah! I hate needing to specify every fricking detail) will be exactly the specified increment away from the (calculated!) last one. And yes, that thus also tries to negate a previous sleep having ended late. In short: The calculated(!) next sleeps termination time is not dependant on how well the previous sleeps and code between them behaved. > the time used to compute the sleep time would be a little later. That doesn't matter, as that "a little later" time would be the same for all the sleeps. In short, the /whole/ output would be delayed a bit. Which, in this case, is of no consequence. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
