This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author matejcik
Recipients giampaolo.rodola, jacques, janssen, matejcik, vbabiy
Date 2009-07-24.15:00:31
SpamBayes Score 2.5081974e-07
Marked as misclassified No
Message-id <>
i believe that the bug lies in bad implementation/backport of feature
from 3.0 patch for issue1251.

see this revision:
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 (
) 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:

without the timeout setting/resetting stuff
Date User Action Args
2009-07-24 15:00:34matejciksetrecipients: + matejcik, janssen, giampaolo.rodola, jacques, vbabiy
2009-07-24 15:00:34matejciksetmessageid: <>
2009-07-24 15:00:32matejciklinkissue5103 messages
2009-07-24 15:00:31matejcikcreate