jan matejek <jmate...@suse.cz> added the comment: i believe that the bug lies in bad implementation/backport of feature from 3.0 patch for issue1251.
see this revision: http://svn.python.org/view/python/branches/release30-maint/Lib/ssl.py?r1=59339&r2=59340 where the code was added for py3k branch. the logic behind that code is that when the timeout is zero (non-blocking socket), but the caller explicitly specifies that they want to block (which only happens when an application handles do_handshake by itself), timeout is set to None and reset to zero after the call. and this change was made to "better support non-blocking sockets", the original patch ( http://svn.python.org/view/python/branches/py3k/Lib/ssl.py?view=diff&r1=58996&r2=58997 ) did not have this code at all on the other hand, what the 2.6 version does is not making any sense. i don't even see how it got to be that way instead of using py3k's do_handshake with optional "block" parameter - seeing as the change was made six months later and changed the API anyway the correct thing to do here is simply if do_handshake_on_connect: self.do_handshake() without the timeout setting/resetting stuff ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5103> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com