Maybe if the patch was regenerated with Mercurial off a public revision, it would work with Rietveld. I have seen non-Mercurial patches work too though. Perhaps this one doesn’t because the line numbers are off compared to the default branch?

See also Issue 18391 discussing extending the existing fromfd() function to automatically determine the socket parameters.

I agree that the name fromfd2() is a bit ugly, although there is precedence at least in Python 2: urllib2, os.popen2(), popen2 module, etc. Maybe other bike shed colours might be from_existing_fd(), using_fd(), fdopen(). Something that suggests creating an object from an FD without duplication.

I wonder if fdtype() is really needed as a public API.

The new fromfd2() API is missing when you do “from socket import * ”. There is a new function <https://docs.python.org/3.6/library/test.html#test.support.check__all__> that may be useful to automate checking for this error.

What prevents this from working on Windows? I understand there is less of a need, but I imagine it would be relatively easy to support.

It looks like some platforms support SO_PROTOCOL and/or SO_PROTOTYPE to get a socket’s protocol: <http://austingroupbugs.net/view.php?id=840>. Also, there might be a Windows-specific SO_PROTOCOL_INFO option.

>>> s
<socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 0)>
>>> SO_PROTOCOL = 38  # On Linux x86-64; see Issue 18391
>>> protocol_struct = Struct("I")
>>> protocol = s.getsockopt(SOL_SOCKET, SO_PROTOCOL, protocol_struct.size)
>>> protocol_struct.unpack(protocol)
(6,)
>>> IPPROTO_TCP
6

IMO if Python grows the ability to determine a socket’s protocol, it might be better for socket.proto to use it automatically, at least if proto=0 was specified to the socket() function.

diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
+.. function:: fromfd2(fd)
+
+   Create a socket object from a file descriptor.  The file descriptor is
+   not duplicated.  The family, type and protocol for the socket are
This needs fixing about how and if the protocol is determined.

+   determined from the file descriptor.  If the file descriptor is not a
+   socket, OSError is raised.  The socket is assumed to be in blocking mode.
:exc:`OSError`

+   The newly created socket is :ref:`non-inheritable <fd_inheritance>`.
This does not seem to be true, nor desirable:

>>> s = socket()
>>> s.get_inheritable()
False
>>> s.set_inheritable(True)
>>> ss = fromfd2(s.fileno())
>>> ss.get_inheritable()
True
>>> s.get_inheritable()
True

+   .. versionadded:: 3.6
+      The returned socket is now non-inheritable.
The whole function is new, not just process inheritance.

diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
+            with s:
+                s2 = socket.fromfd2(s.fileno())
+                with s2:
Isn’t this incorrect due to closing the same file descriptor twice? I think you should use socket.detach(). See Issue 26685, whose changes should raise an exception for this bug in 3.6.

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
+    if (!S_ISSOCK(st_fd.st_mode)) {
+        PyErr_SetString(PyExc_ValueError, "fdtype: "
+                        "file descriptor is not a socket");
This seems to be contrary to your documentation. Also, perhaps it is good enough to let getsockopt() later raising ENOTSOCK?

+    union sockaddr_union sockaddr = {};
Why not just use a struct sockaddr? All we need is the sa.sa_family field right?