Andrew Svetlov added the comment: >From my perspective the problem is: many asyncio calls schedules a delayed >activity internally. E.g. `task.cancel()` doesn't cancels immediately but requires at least one extra loop iteration. The same is true for `transport.close()` -- it doesn't close socket in the call. This behavior is encouraged by asyncio design and many third-party libraries just call `transp.close()` without waiting for upcoming `protocol.connection_lost()` callback.
I don't think it's a big problem, especially for server code. But when users write small client tool they need to do extra no-op loop iterations before `loop.close()` call. Waiting for no scheduled by `loop.call_soon()` callbacks makes no sense I believe. I could open a can of worms by introducing another weird side effects. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28212> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
