Martin Panter added the comment: For the record, the SMTP scenario was Issue 17498, where code that is about to raise an exception attempts an RSET command that could also fail.
I do think each change in my patch is essentially the same case: restoring the invariant expected by the __exit__() method, that either the protocol state allows QUIT, or there is no connection. But I agree it may help divide this into smaller pieces. I am uploading getlongresp-loop.patch, which fixes just the receiving loop in _getlongresp(). I have also added some logic to avoid errors raised when flushing and closing the socket do not mask the original exception, which I understand David was concerned about. I guess it is possible (though unlikely) that an EPIPE or ECONNRESET flushing the send buffer could mask a KeyboardInterrupt raised inside the loop. Sorry I took a while to follow up on this, but please have a look and let me know if this simplified patch makes any sense. ---------- Added file: http://bugs.python.org/file39490/getlongresp-loop.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22350> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
