On 27 May 2010, at 17:53, Floris Bruynooghe wrote: > On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote: >> On 27/05/10 00:31, Brian Quinlan wrote: >> >>> You have two semantic choices here: >>> 1. let the interpreter exit with the future still running >>> 2. wait until the future finishes and then exit >> >> I'd go for (1). I don't think it's unreasonable to >> expect a program that wants all its tasks to finish >> to explicitly wait for that to happen. > > I'd got for (1) as well, it's no more then reasonable that if you want > a result you wait for it. And I dislike libraries doing magic you > can't see, I'd prefer if I explicitly had to shut a pool down. And > yes, if you shut the interpreter down while threads are running they > sometimes wake up at the wrong time to find the world around them > destroyed. But that's part of programming with threads so it's not > like the futures lib suddenly makes things behave differently. > > I'm glad I'm not alone in preferring (1) tough. Keep in mind that this library magic is consistent with the library magic that the threading module does - unless the user sets Thread.daemon to True, the interpreter does *not* exit until the thread does. Cheers, Brian
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4