== The cost of an API mistake in the socket module's _fromfd()_ Suppose that you get handed a file descriptor that is a socket and you want to turn it into a Python [[socket object http://docs.python.org/2/library/socket.html#socket-objects]] (clearly you are on Unix). The [[socket module http://docs.python.org/2/library/socket.html]] has a Unix-only _fromfd()_ function with the argument signature: > socket.fromfd(*fd*, *family*, *type*[, *proto*]) So how do you determine the *family* and *type* of the socket file descriptor you have, since you have to supply them? Ha ha, silly you. The helpful socket module answer is 'we're not going to help you with that'. In fact the socket module provides no direct, official way of doing this; in order to do so, you need to sneak in through two increasingly baroque back doors in just the right way. (And at least some things may go wrong if you get it wrong.) The official Unix way of finding out the type of a socket is to issue a _``getsockopt(fd, SOL_SOCKET, SO_TYPE)''_ call. Unfortunately the socket module does not allow you to do _getsockopt()_ on file descriptors, only on actual socket objects. Fortunately the socket module does not actually care if you get the family and type right, at least as far as _getsockopt_ goes, so: .pn prewrap on > s = socket.socket(fd, socket.AF_UNIX, socket.SOCK_STREAM) > styp = s.getsockopt(socket.SOL_SOCKET, socket.SO_TYPE) Inconveniently there is no portable _getsockopt()_ query that will give you the family. The official Unix way of doing this is more or less to make a _getsockname()_ call with a plain _struct sockaddr_ and then examine the ((sockaddr.sa_family)) field afterwards. The socket module doesn't provide a direct way to make raw _getsockname()_ calls or see ((sa_family)), but it does have a _.getsockname()_ method on socket objects that gives you decoded, friendly results. When I started this exercise, I expected that calling _s.getsockname()_ on a socket created via _fromfd()_ with the wrong family would raise a _socket.error_ exception. I was far, far too innocent. Depending on exactly what you do, you get either the correct _getsockname()_ results for the actual type of socket you are dealing with or, sometimes, interestingly mangled results. On Python 3 you can also get _UnicodeDecodeErrors_ in the right circumstances. The safest thing to do turns out to be to make your dummied-up socket be an ((AF_UNIX)) socket; you can then call _s.getsockname()_ with reasonable safety and examine the resulting name to reverse engineer the socket family. (It's the safest because ((AF_UNIX)) sockets have the biggest version of _struct sockaddr_; you've got the greatest chance that a full copy of any other socket family's _sockaddr_ structure will fit into it. Python is presumably blindly making the _getsockname()_ call with the _sockaddr_ appropriate for the apparent family, then interpreting it based on the actual returned socket family. If the _sockaddr_ structure is truncated, odd things happen.) What this really illustrates is that the socket module completely dropped the ball on _fromfd()_'s API. You should not be able to give it a *family* and *type* at all; since the rest of the socket code clearly counts on those being correct, the socket module code should determine them itself. This would be easier to use and render _.getsockname()_ non-crazy. (_getsockname()_'s implementation is completely sensible if a socket's *family* is always correct.)