A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-May/100404.html below:

[Python-Dev] PEP 3148 ready for pronouncement

[Python-Dev] PEP 3148 ready for pronouncement [Python-Dev] PEP 3148 ready for pronouncementFloris Bruynooghe floris.bruynooghe at gmail.com
Thu May 27 09:53:49 CEST 2010
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.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
More information about the Python-Dev mailing list

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