Le lundi 19 janvier 2015, Luciano Ramalho luci...@ramalho.org a écrit :
Can I conclude that in practice, close() should not be called at all
unless your own code actually created the loop instead of merely
fetching it with asyncio.get_event_loop()?
Event loops must be closed. The first call
Ok, that makes sense, thanks!
On Sunday, January 18, 2015, Guido van Rossum gu...@python.org wrote:
Yes. It's a bit like memory allocation -- if you don't own it, don't free
it.
On Sun, Jan 18, 2015 at 3:41 PM, Luciano Ramalho luci...@ramalho.org
Yes. It's a bit like memory allocation -- if you don't own it, don't free
it.
On Sun, Jan 18, 2015 at 3:41 PM, Luciano Ramalho luci...@ramalho.org
wrote:
Like Victor Stinner in this bug report [1], I was craving for a
context-manager enabled loop so I did not forget to close() it.
But
Like Victor Stinner in this bug report [1], I was craving for a
context-manager enabled loop so I did not forget to close() it.
But reading Guido's last message rejecting that bug, it seems callign
loop.close() is only recommended if you own the loop -- while most
asyncio users probably don't own
Hi,
I've did a new release of API-Hour based on your comments you sent me
privately.
As a remember, API-Hour helps you to create AsyncIO (HTTP, SSH) daemons,
with multiprocessing pattern included.
The changes:
1. An all-in-one Python script example, to test quickly API-Hour without
