[issue25586] socket.sendall broken when a socket has a timeout

Martin Panter added the comment: For what it’s worth, there could be obsure cases where sending more data might be okay. I prefer the original version (but can settle for either). Here’s a third alternative: Considering this loss of information, it is generally best not to send any more data

[issue25586] socket.sendall broken when a socket has a timeout

STINNER Victor added the comment: I'm not a big fan of "may" in documentation. I would prefer to rephrase it as an advice. Example: "Considering the loss of information, it's better to not retry sending data to the socket anymore." -- ___ Python tr

[issue25586] socket.sendall broken when a socket has a timeout

STINNER Victor added the comment: Note: socket-docs.patch file is strange, it looks like you removed the first line starting with "diff", and so we don't get the [Review] button. -- ___ Python tracker

[issue25586] socket.sendall broken when a socket has a timeout

Martin Panter added the comment: That was kind of what I had in mind. The only change I would make is to restore the comma to “On error (including socket timeout), an exception . . .”. I’ll try to commit this in a few days if nobody has anything else to say. -- stage: -> patch review

[issue25586] socket.sendall broken when a socket has a timeout

Jakub Stasiak added the comment: That's fair and thanks for the links. Please find a quick patch attached, feel free to use that or any modification of it. While I believe the documentation is technically correct right now it won't hurt to clarify this I think. -- keywords: +patch Add

[issue25586] socket.sendall broken when a socket has a timeout

STINNER Victor added the comment: I don't really understand why do even you consider the behaviour has a bug or a trap. On timeout, the most common behaviour is to give up on the whole client. I don't know code trying to resend the same data in case of timeout. Describing the behaviour on the

[issue25586] socket.sendall broken when a socket has a timeout

Martin Panter added the comment: Personally I would avoid big red warning boxes in 90% of the cases people suggest them, including this one. But maybe we can see what others think. -- ___ Python tracker __

[issue25586] socket.sendall broken when a socket has a timeout

Jakub Stasiak added the comment: This is exactly what I'm thinking. Do you think it's sensible to move that sentence + some additional information (following your suggestion) into a "Warning" block? -- ___ Python tracker

[issue25586] socket.sendall broken when a socket has a timeout

Martin Panter added the comment: Maybe it would be reasonable to expand on that “On error” sentence. I imagine the main errors that would cause this situation are a timeout as you say, and also a blocking exception. Also, you could point out that if you have lost record of how much has already

[issue25586] socket.sendall broken when a socket has a timeout

Jakub Stasiak added the comment: Martin: While I'd consider timeout in HTTPConnection(timeout=...) or urlopen(timeout=...) to be the timeout for the entire operation, just just for the data sending part and HTTPConnection/urlopen can achieve the timeout behavior using just send I concede there

[issue25586] socket.sendall broken when a socket has a timeout

Martin Panter added the comment: I don’t like the sound of improvement 2. I think it would break existing use cases, e.g. HTTPConnection(timeout=...), urlopen(timeout=...). If you want a HTTP request to abort if it takes a long time, how is that behaviour broken? Regarding improvement 1, I thi

[issue25586] socket.sendall broken when a socket has a timeout

STINNER Victor added the comment: FYI the behaviour of socket.socket.sendall() regarding timeout has been modified in Python 3.5: https://docs.python.org/dev/library/socket.html#socket.socket.sendall "Changed in version 3.5: The socket timeout is no more reset each time data is sent successful

[issue25586] socket.sendall broken when a socket has a timeout

New submission from Jakub Stasiak: It is my understanding that socket.sendall effectively calls the underlying socket.send's implementation in a retry loop, possibly multiple times. It is also my understanding that each one of those low level send calls can timeout on its own if a socket timeo