Currently, the C module _socket has an useful representation of socket: it gives the file descriptor, family, type, etc. The Python socket module only shows the memory address. Example:

$ ./python -c 'import _socket; s=_socket.socket(); print(repr(s));'
<socket object, fd=3, family=2, type=1, protocol=0>

$ ./python -c 'import socket; s=socket.socket(); print(repr(s));'
<socket._socketobject object at 0x7fad1fdcbba0>

I propose to backport repr(socket.socket) from Python 3.5 to Python 2.7. With the patch, the Python socket even contains *more* information than the C module (laddr and raddr). Example with the patch applied:

$ ./python -c 'import socket; s=socket.socket(); print(repr(s));'
<socket._socketobject fd=3, family=2, type=1, proto=0, laddr=('0.0.0.0', 0)>

In Python 2.7, when a socket is closed, it drops the underlying C _socket object. So it's not possible to provide a better representation than:

$ ./python -c 'import socket; s=socket.socket(); s.close(); print(repr(s));'
<socket._socketobject[closed]>

I don't want to change the design of the Python module, Python 2.7 is very stable. I don't want to take the risk of breaking anything.

I also fixed repr(_socket.socket) on Windows 64-bit for closed sockets (on Python 2.7, 3.4 and 3.5):

changeset:   91881:04c916a1e82f
branch:      2.7
tag:         tip
user:        Victor Stinner <victor.stinner@gmail.com>
date:        Sat Jul 26 14:52:55 2014 +0200
files:       Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c
description:
Fix repr(_socket.socket) on Windows 64-bit: don't fail with OverflowError
on closed socket.


changeset:   91880:a86c273a1270
branch:      2.7
user:        Victor Stinner <victor.stinner@gmail.com>
date:        Sat Jul 26 14:47:56 2014 +0200
files:       Modules/socketmodule.c
description:
socketmodule.c: backport INVALID_SOCKET from Python 3.5 to simplify the code

Antoine, what do you want me to do?  I think improving __repr__ of a socket sounds fine for some Python 2.7 bugfix release.

I afraid this can break doctests. Isn't this against policy?

I don't think it's against policy. Do doctests even work for objects that have an address as part of their repr()?

See for example test_generators, test_genexps, test_xml_etree or 
ctypes.test.test_objects.

    >>> dict(a = (i for i in xrange(10))) #doctest: +ELLIPSIS
    {'a': <generator object <genexpr> at ...>}

    >>> repr(element)   # doctest: +ELLIPSIS
    "<Element 't\\xe4g' at 0x...>"

But unit tests can be broken too. When I enhanced reprs this week (issue22031, 
issue22032), I needed to correct failed tests. Due to this facts I applied 
patches only to 3.5.

OK, I'm convinced. Sorry Victor.

On Saturday, July 26, 2014, Serhiy Storchaka <report@bugs.python.org> wrote:

>
> Serhiy Storchaka added the comment:
>
> See for example test_generators, test_genexps, test_xml_etree or
> ctypes.test.test_objects.
>
>     >>> dict(a = (i for i in xrange(10))) #doctest: +ELLIPSIS
>     {'a': <generator object <genexpr> at ...>}
>
>     >>> repr(element)   # doctest: +ELLIPSIS
>     "<Element 't\\xe4g' at 0x...>"
>
> But unit tests can be broken too. When I enhanced reprs this week
> (issue22031,
> issue22032), I needed to correct failed tests. Due to this facts I applied
> patches only to 3.5.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue22081>
> _______________________________________
>

Personally I don't think it is (or should) be against policy to change reprs, there's not really any way to improve them otherwise.

That said, my excitement level about this issue is pretty low, so I won't argue more than this :-)

> I afraid this can break doctests. Isn't this against policy?

Ok, I close the issue. A workaround is to use repr(sock._sock) to use repr(_socket.socket) which contains a lot of information.