Guido van Rossum added the comment: > 1. You have to manage the lifecycle of the executor yourself, rather than > letting asyncio do it for you > 2. There's no easy process wide way to modify the size of the background task > thread pool (or switch to using processes instead)
But if that's what you want, adding a helper or helpers to concurrent.futures makes more sense than adding it to asyncio, which is primarily about using an event loop, *not* threads. > 3. There's no easy way for background tasks themselves to use asynchronous IO But how does your proposal help for that? The function passed to background_call() is in no way enabled to do async I/O -- it has no event loop and it is not a coroutine, and it's running in a separate thread. > With the switch to "background_call" as the name, I'd modify the > implementation to detect coroutines and schedule them as tasks rather than > running them in the executor. Honestly, I think that convenience routines that fuzz the difference between synchronous functions (to be run in a thread) and coroutines don't do anyone a service -- an API should educate its users about proper use and the right concepts, and this sounds like it is encouraging staying ignorant. > However, I think it's clear that the idea and its potential benefits are > sufficiently unclear that making the case effectively may require a PEP. > That's probably worth doing anyway in order to thrash out more precise > semantics. Or you could just give up. Honestly, I am liking this less and less the more you defend it. That's a classic sign that you should give up. :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24571> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
