Author kristjan.jonsson
Recipients gregory.p.smith, gvanrossum, kristjan.jonsson
Date 2009-01-19.11:58:10
SpamBayes Score 8.95706e-12
Marked as misclassified No
Message-id <>
I'm reawakening this because needs to 
be ported to py3k.
In py3k, a socket.fileobject() is still created with bufsize(0), 
although now the reasoning is different:

 def __init__(self, sock, debuglevel=0, strict=0, method=None):
        # XXX If the response includes a content-length header, we
        # need to make sure that the client doesn't read more than the
        # specified number of bytes.  If it does, it will block until
        # the server times out and closes the connection.  (The only
        # applies to HTTP/1.1 connections.)  Since some clients access
        # self.fp directly rather than calling read(), this is a little
        # tricky.
        self.fp = sock.makefile("rb", 0)

I think that this is just a translation of the old comment, i.e. a 
warning that some people may choose to call .recv() on the underlying 
Now, this should be far more difficult now, with the newfangled IO 
library and all, and since the sock.makefile() is now a SocketIO object 
which inherits from RawIOBase and all that.  It's tricky to excracth 
the socket to do .recv() on it.  So, I don't think we need to fear 
buffering for readline() anymore.

Or, is the comment about someone doing a in 
stead of a  In that case, I don't see the 
problem.  Of course, anyone reading N characters from a socket stream 
may cause blocking.

My proposal is to remove the comment above and use default buffering 
for the fileobject.  Any thoughts?
Date User Action Args
2009-01-19 11:58:14kristjan.jonssonsetrecipients: + kristjan.jonsson, gvanrossum, gregory.p.smith
2009-01-19 11:58:13kristjan.jonssonsetmessageid: <>
2009-01-19 11:58:13kristjan.jonssonlinkissue4448 messages
2009-01-19 11:58:10kristjan.jonssoncreate