I agree (unsurprisingly since it seems I brought it up in the first place :-). I wonder if the parameter name should be other than timeout, since it may surprise people that a readline() with a timeout of 5 secs can take longer than 5 secs to complete. But I have no good suggestion for a better name, unless you like low_level_timeout.
I also wonder if it would make sense to set the timeout as part of the stream state rather than passing it on every call? (The API gets so noisy when all methods have this extra parameter. On Thu, Sep 3, 2015 at 8:04 AM, Victor Stinner <[email protected]> wrote: > Hi, > > I proposed a patch to add timeout to StreamReader read methods: > http://bugs.python.org/issue23236 > > The idea is to reset the timeout each time we receive new data. It is > less strict than wait(read(), timeout) which restricts the total > duration. The subtle risk is that a server can "DoS" a client by > sending slowly the reply by packets of a single byte every N seconds. > > But you want combine the two timeouts. For example, > wait(readline(timeout=5.0), 60.0) fails if the server takes longer > than 5 seconds to send data or if the server doesn't send a newline > before 60 seconds. > > What do you think? Is it an useful feature? > > -- > > On Python <= 3.4, socket.sendall() resets the timeout each time that > we succeeded to send at least one byte. The behaviour changed in > Python 3.5: the timeout is not more reset, it's now the maximum total > duration to send all bytes. I found and fixed this when I worked on > the PEP 475 (EINTR). Related discussion on python-dev: > https://mail.python.org/pipermail/python-dev/2015-April/139001.html > > There is also a pending patch to add a recvall() method to socket.socket: > http://bugs.python.org/issue1103213 > > Victor > -- --Guido van Rossum (python.org/~guido)
