On Monday, October 31, 2016 at 6:27:57 PM UTC+2, Guido van Rossum wrote: > > It's an interesting problem. I would like to rephrase your conclusion: > the implicit loop should only be used when the object you are creating > has a shorter (or equal) lifetime than the loop. I would also think > that the real problem with the code example is that it creates a > variable with global lifetime. That's really an antipattern, > especially when it comes to network connections. But I'm not sure we > can blame asyncio or motor for that -- it's really class A that's to > blame. > > Yes, lifetime of object created with (implicit) loop should be shorter than loop's one. Unfortunately it's problem on both sides: user creates silly code but he will blame library author because the library (motor in my example) will hang silently.
I could add a warning to aiohttp.ClientSession for preventing this behavior but covering the issue by asyncio itself could help to newbies and library writers. The same problem is present in asyncio classes itself: Lock, Queue, streams could be created with global life time and they are will hang if used from different loop. > > Regarding testability of class A, I presume tests could just set a new > default loop and then re-assign A.client = > motor.motor_asyncio.AsyncIOMotorClient()? Or is that class under the > hood a singleton that just wraps more state with global lifetime? Then > that would be a problem. > > It has a smell of monkey-patching. What we really need is preventing creation classes like AsyncIOMotorClient if loop is not running.
