On Thu, Sep 25, 2008 at 10:57 PM, Gregory P. Smith
<report@bugs.python.org> wrote:
> The whole socket._io_refs thing looks like a real design flaw.  What is
> its actual intended purpose?

The original purpose was to support the original semantics of the
.makefile() method on Windows which doesn't have dup() (or at least
didn't have it when this hack was first invented, many years ago). We
almost got rid of it for Py3k, but then we realized that the same
issue (sort of) exists for ssl, and that's why it's still there and
used everywhere, not just on Windows.

> When close is called on the socket object itself, the socket MSUT be
> closed.  Why is our API otherwise?

See above -- the underlying connection must remain open until the
stream created with .makefile() is also closed. (These are the
original dup-based semantics.)

Why do you say MUST? Is there an Internet standard that requires this?

> Its up to the programming to ensure that no other references to that
> socket wrapped in whatever layers will be used after that, if they are
> they'll eventually get errors when an IO occurs.

No, the .makefile() API always promised that the connection remained
open until you closed (or lost) the stream.

> I think this behavior started with this change:
>
> ------------------------------------------------------------------------
> r56714 | jeremy.hylton | 2007-08-03 13:40:09 -0700 (Fri, 03 Aug 2007) |
> 21 lines
>
> Make sure socket.close() doesn't interfere with socket.makefile().

No, it's much, much older than that. That change was probably just a
refactoring -- it's been refactored a number of times.