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 with this -- it would both ensure that the API is widely usable and that it will be widely used (assuming the PyPI package is available for a wide range of versions, e.g. 3.5 and later).
On Sat, Feb 15, 2020 at 3:12 PM Bar Harel firstname.lastname@example.org wrote:
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 benefits.
You can say it about every python feature. Using a new feature restricts you to the latest python version. Eventually it will trickle down.
The fact that it wasn’t there from the start like GCD’s default queues were means people have already come up with other solutions and they might not want a different one.
There are no other solutions to that problem. Up until now, people created their own solutions, and their own threads, out of necessity. They simply didn't have a choice. I've witnessed a large project which used many 3rd party packages, and had no less than 148 (!!!) threads, since every package had to create it's own thread, waiting in the background and doing nothing.
Since I'm a backend developer, I can see it being highly used in my field. Metrics? Server statistics? Lot's of times it's a fire-and-forget mechanism, that just needs to execute stuff in the background. But heck, even using logging.QueueListener creates an unavoidable thread.
Right now there's no standardized way to do so. I thought of concurrent.futures with a get_global_pool() as a simple solution, but did not know about GCD. We can try and implement something equivalent on a provisional basis, that newer packages will use. There's no need to port older code to use it, as it will slowly fade away.
once it goes into the stdlib, its interface is fixed forever.
Well, it just means we have some thinking to do. Rome wasn't built in a day.
With all the benefits of creating a PyPi package, I'm afraid adoption rate won't be high if it won't be a standard. The solution to the issue can either be starting with stdlib on provisional, or developing and releasing under a well known developer's name, much like PyPa or aio-libs.
These questions are eventually up for discussion. I'm just a single developer with a small perspective, and don't pretend to know the answer :-)
Perhaps more devs will weigh in and give their opinion.
Always happy to learn, Bar Harel. _______________________________________________ Python-ideas mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/HGTACG... Code of Conduct: http://python.org/psf/codeofconduct/