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 r.david.murray
Recipients amaury.forgeotdarc, beazley, dabeaz, gregory.p.smith, loewis, ned.deily, pitrou, r.david.murray, rosslagerwall, roysmith
Date 2011-10-20.18:01:14
SpamBayes Score 1.383099e-05
Marked as misclassified No
Message-id <1319133675.3.0.709660908857.issue7322@psf.upfronthosting.co.za>
In-reply-to
Content
I don't think it is optimistic.  The poplib transaction pattern is: send a command, get a response.  If the response is not properly terminated, throw it away.  Send a new command, get a response.  There's no ambiguity there.  In addition, this is a common tcp client-server model, so I think it applies more widely than just poplib.

Please note that the timeout is *not* because the socket data transmission has timed out and data was lost in transit.  There are no partially filled readline buffers in this scenario.  The timeout is because the client is waiting for a *line* of data that the server never sends.  Again, this is likely to be a common failure mode in tcp client/server applications, and to my mind is exactly what the timeout parameter to the constructor is most useful for.
History
Date User Action Args
2011-10-20 18:01:15r.david.murraysetrecipients: + r.david.murray, loewis, beazley, gregory.p.smith, amaury.forgeotdarc, roysmith, pitrou, ned.deily, dabeaz, rosslagerwall
2011-10-20 18:01:15r.david.murraysetmessageid: <1319133675.3.0.709660908857.issue7322@psf.upfronthosting.co.za>
2011-10-20 18:01:14r.david.murraylinkissue7322 messages
2011-10-20 18:01:14r.david.murraycreate