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 <[email protected]> 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 protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/HGTACGSP524AR4YKJ22LO44IUX2D7MFH/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/AT24S6KF264CRSFQ55TMHC627TJEKMY5/ Code of Conduct: http://python.org/psf/codeofconduct/
