socket.settimeout(t) -- can set the socket in blocking mode, when t==0.
socket.setblocking(flag) -- sets in blocking or non-blocking mode.
socket.gettimeout() -- returns 0 when socket is in non-blocking mode.
socket.gettimeout() is the only easy way of checking if the socket is non-blocking or blocking, but it's not intuitive to use it. It's especially strange that we have a setblocking() method without a corresponding getblocking().
I propose to add a 'socket.getblocking() -> bool' method.
It looks like we have a bug with 'sock.settimeout()' and non-blocking/blocking modes (or maybe this is a feature?)
to make a socket non-blocking, we call 'sock.settimeout(0)'.
to make a socket blocking, we call 'sock.settimeout(None)'.
What happens if we call sock.settimeout(t), where t > 0? The internal timeout field of the socket object will simply be set to 't'. What happens if the socket was in a non-blocking mode? Nothing, it stays in non-blocking mode.
What it means: suppose you have a non-blocking socket. You call socket.settimeout(10), and most likely you wanted to make it blocking again. Because all operations on the socket become blocking from moment (sock_call_ex repeats on EWOULDBLOCK and EAGAIN).
Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug?
It appears the the timeouts situation is a bit more complex. It's perfectly normal for a Python socket object to be in a "blocking" mode and for its FD to be in a non-blocking mode. Read more about this in the latest docs update to the PR: adcc91f