If one has a non-blocking socket, 'sock', and uses
'sock.makefile()' to create file-like object out of it,
there exists the possibility (even probability) of data
loss in the event of an EAGAIN error.

The code that comprises _fileobject in socket does not
try to catch EAGAIN.  In the event that the read()
operation does not encounter EOF, but *has* read data
(and then gets an EAGAIN) such as when there is less
than 8KB of data to read, the socket.error traceback is
handed back to the caller of read and the read data is
discarded.  This is horrible. The _fileobject read
routine (and probably write, too) should catch
socket.error and check it for EAGAIN, and in that case,
return what it has already read (if anything). 

Logged In: YES 
user_id=8446

An improvement would be to allow EAGAIN to surface only if
it happens as the /first/ read. 

Is this still valid?

Should work fine under 3.x.

Shall we close this ticket then?

Surely if there is data loss this *has* to be fixed in 2.x?
I'm seeing this a *lot* using Twisted which, I believe isn't fully 3.x ported yet, so we have to support 2.x for now.

The simple fact of the matter is that socket.makefile() has never worked for non-blocking sockets on 2.x. I doubt Twisted would be so broken as to use it in that context, but if that's the case, you should report a bug to them. If it's your own code, just use the socket directly (and call recv() and friends).

3.x should work fine, in that read() will return a short read (or None if nothing could be read before EAGAIN). Still, more complex calls such as readline() may still give incorrect results.

(closed as won't fix, sorry)