[Python-Dev] sock.close() not closing? (original) (raw)

Bill Janssen janssen at parc.com
Wed May 7 19:29:02 CEST 2008

I would be okay with changing the requirements in Py3k so that you are required to keep the socket object open at least as long as you plan on using the derived stream(s), but this will require some careful redesign, especially in the light of SSL support. (Read ssl.py and ssl.c to understand the level of intertwinement.) In 2.6 I think we should leave the design alone (to the point that it hasn't already changed due to Bill Janssen's providing a new, enhanced SSL implementation) for best compatibility.

I'd be perfectly happy to get rid of this. It's not SSL in particular that requires it, if I'm remembering correctly, it's really the HTTP library -- HTTP over SSL was failing when we tried to change this. The HTTP client-side library calls "makefile" on the socket, then closes it, then passes the file returned from "makefile" on to application code to work with. That code merrily reads and writes from the (closed) socket to read responses from the remote Web server. This particular nasty pattern is deeply entwined in all the code that touches the HTTP library in any way, so it will be a big job to get rid of it -- basically re-writing HTTP support and all the services which use it. I didn't want to get into that :-).

And I agree with Guido; it doesn't make sense to try to fix this in 2.6. And plan a few months of work to fix it in 3.x; even then, I think you'll break a lot of user code (that won't close the socket when they're finished with it). On the other hand, maybe it's not so bad; maybe you could just (in httplib) read the whole response into a StringIO, and pass that on to the client code.

Bill

More information about the Python-Dev mailing list