If the server failed to close a transaction the protocol stream is over
unless you mime relying on hope and luck. Poplib has a nasty set of server
implementation bugs to work around here.

Readline as defined today no longer suits its needs but I still strongly
believe the behavior of shutting reading down after a timeout is a good one.

One thing that would solve your common case: don't shut down reading on a
readline timeout if zero data was received into the internal line buffer.
Readline could indicate this by modifying the timeout exception being raised
to indicate if it can recover or not. The flag should only be set if it was
unrecoverable.
On Oct 20, 2011 11:01 AM, "R. David Murray" <report@bugs.python.org> wrote:

>
> R. David Murray <rdmurray@bitdance.com> added the comment:
>
> 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.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7322>
> _______________________________________
>