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

[Bill Janssen]

> 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