> Here is the issue (put plainly):

Unfortunately, I still don't understand it. I go through your plain
elaboration below.

> Python sockets support a notion of timeout  (note this notion is not
> reflected in the OS socket API).

Correct.

> The python socket implementation of timeouts uses the underlying OS /
> socket API to provide this by setting the socket to nonblocking and
> setting a timeout value in a Python object that holds socket info.

Correct.

> This implementation assumes that the OS sets any socket it receives
> via accept to nonblocking.   (this is a false assumption on BSD)

Not true. It doesn't assume that (it doesn't assume the reverse,
either).

> The end result is that the OS has a nonblocking socket and the Python
> object thinks it is blocking.   This is why the socket object in
> Python has timeout=None yet calling fcntl shows the socket is
> nonblocking.

That conclusion is flawed. Python has not associated a timeout with
the socket. It makes no claims as to whether the socket is blocking
or not. So you have created a non-blocking socket without timeout.

I cannot see anything wrong with such a thing. The system explicitly
supports such sockets (and, as you point out, it doesn't even have
the notion of "per-socket timeouts"). And so should Python support
them as well.

> Calling code paths that handle timeouts and expect the socket to
> block causes bugs like I described in my code.   This behavior is
> clearly wrong under any interpretation!

What about my interpretation above?
1