On 10 Dec., 00:11, [EMAIL PROTECTED] wrote: > >> # Monitoring loop. > >> loops = 0 > >> # We're going to loop ten times per second using an integer count, > >> # so multiply the seconds parameter by 10 to give it the same > >> # magnitude. > >> intint = int(self.progress_interval*10) > > Is this not an unnecessary complication? > >> # isAlive will be false after dowork returns > >> while worker.isAlive(): > >> loops += 1 > >> # Wait 0.1 seconds between checks so that we aren't chewing > >> # CPU in a spin loop. > >> time.sleep(0.1) > > Why not just call this with progress_interval directly? > > Because then the program make take up to progress_interval seconds to > complete even after all the work is done. For a long running program > and a short progress_interval that might not matter, so yes, that would > be a reasonable simplification depending on your requirements. > Ah, OK. With my timer.cancel() statement in my original proposal I avoided that. > > > OK. I agree this is a more elegant implementation, although I my mind, > > I find it more natural if the reporting goes on in a subthread, but > > You could pretty easily rewrite it to put the reporter in the subthread, > it was just more natural to _me_ to put the worker in the subthread, > so that's how I coded it. Note, however, that if you were to write a > GUI front end it might be important to put the worker in the background > because on some OSes it is hard to update GUI windows from anything > other than the main thread. (I ran into this in a Windows GUI ap I > wrote using wxPython). > Ah, yes, you right. For GUIs this is often quite important. I don't do much GUI, so This is not something I had strongly in mind.
Br, -- Slaunger -- http://mail.python.org/mailman/listinfo/python-list
