why does socket.makefile require non-blocking mode?

[Forest]

Bryan Olson wrote:

>Looking at the code for the existing _fileobject's read method, it
>will loose data it has already read if a socket.recv() call raises
>an exception. The function keeps buffers in a local variable that
>will be lost if an exception exits the scope. That much could be
>fixed with a try...finally. Other methods have similar problems.

Just as I thought.  Thanks for being my extra set of eyes.

>>I wanted to use file-like objects with socket timeouts, so I ended up
>>writing my own replacement for socket._fileobject.  I'd appreciate it
>>if someone could either explain to my why my new class was unnecessary,
>>or else encourage me to contribute it as a patch to the socket module.
>
>Sure, fix it.

Yeah, I'll give it some more thought.

>A harder problem is that it doesn't play nice with select().

I guess you mean that since _fileobject.read() calls recv() multiple
times, the second and later calls might block even if select() said the
socket was
readable.  That should be fixable by catching EAGAIN / EWOULDBLOCK and
returning early, shouldn't it?  This idea seems consistent with the normal
file object's read() method docs, which say, "in non-blocking mode, less
data than what was requested may be returned."  Making write() and flush()
friendly in non-blocking mode might be at little trickier.