[Python-ideas] Re: Global thread executor

2020-02-15 Thread Guido van Rossum
So there's one reason to put this in the stdlib: so that stdlib modules (like logging.QueueListener which you mentioned) can use it. There should still a backport so that 3rd party packages have a simple way of using this for earlier Python versions. A PEP would be the best way to make progress w

[Python-ideas] Re: Global thread executor

2020-02-15 Thread Bar Harel
> > The question is, if we added, say, a > concurrent.futures.get_shared_thread_pool_executor function today, would > people change all of the popular libraries to start using it? Probably not, > because then they’d all have to start requiring Python 3.10. In which case > we wouldn’t get the benefi

[Python-ideas] Re: Global thread executor

2020-02-15 Thread Andrew Barnert via Python-ideas
On Feb 15, 2020, at 05:40, Bar Harel wrote: > > If we would have had a global ThreadPoolExecutor, we could have use it > exactly for that. The threads would be shared, the overhead would only occur > once. Users of the executor will know that it's a limited resource that may > be full at times