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
>
> 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
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