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 may be valid use cases for "either
sendall succeeds or we don't care about what we've sent anyway" and in this
light my second suggestion is problematic.
Victor: The behavior change in 3.5 does't affect my concern from what I see.
The concern is sendall timing out after some data has already been sent which
can create some subtle issues. I've seen code like this:
def x(data, sock):
while True:
# some code here
try:
sock.sendall(data)
return
except timeout:
pass
Now I'll agree the code is at fault for ever attempting to retry sendall but I
also think the API is easy to misuse like this. And it many cases it'll just
work most of the time because sendall won't timeout.
Maybe explicitly mentioning sendall's behavior concerning sockets with timeouts
could improve this? I'm honestly not sure anymore, technically "On error, an
exception is raised, and there is no way to determine how much data, if any,
was successfully sent." should be enough.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25586>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
