> On 9 Jun 2017, at 16:40, Guido van Rossum <gu...@python.org> wrote: > > Also, I don't think the situation with explicitly passing loop= is so > terrible as you seem to think. If you rely on the default event loop, you > rely on there *being* a default event loop, but there will always be one > unless an app goes out of its way to create an event loop and then make it > not the default loop. Only the asyncio tests do that. There are a few things > you can't do unless you pass an event loop (such as scheduling callbacks > before the event loop is started) but other than that it's really not such a > big deal as people seem to think it is. (You mostly see the pattern because > asyncio itself uses that pattern, because it needs to be robust for the > extreme use case where someone *does* hide the active event loop. But there > will never be two active event loops.)
My concern with multiple loops boils down to the fact that urllib3 supports being used in a multithreaded context where each thread can independently make forward progress on one request. To establish that with a synchronous codebase you either need one event loop per thread or you need to spawn a background thread on startup that owns the only event loop in the process. Generally speaking I’ve not had positive results with libraries spawning their own threads in Python. In my experience this has tended to lead to programs that deadlock mysteriously or that fail to terminate in the face of a Ctrl+C. So I tend to prefer to have users spawn their own threads, which would make me want a “one-event-loop-per-thread” model: hence, needing a loop parameter to pass around prior to 3.6. I admit that my concerns here regarding libraries spawning their own threads may be overblown: after my series of negative experiences I basically never went back to that model, and it may be that the problems were more user-error than anything else. However, I feel comfortable saying that libraries spawning their own Python threads is definitely subtle and hard to get right, at the very least. Cory _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
