Guido van Rossum added the comment:
Well, calling close() is best practice *if you own the loop*. But the thing is
that you may not own what get_event_loop() returns, and in fact in most cases
where it is called you don't own it. This is very different from files:
with open(...) as f:
...
In that idiom you clearly own f. Both of these are also very different from
locks and the like, because you can repeatedly acquire and release a lock (but
you can only close a file or event loop once).
I tried to come up with a design for a helper that in __enter__() creates a new
event loop and makes it the current event loop, then in __exit__() closes it
and sets the current event loop to None. But this doesn't work well with the
way get_event_loop() can sometimes auto-creates the loop.
Therefore I am closing this as "rejected".
----------
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
type: -> behavior
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19860>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
