How to create a socket.socket() object from a socket fd?

[Grant Edwards]

Newsgroups: gmane.comp.python.general
From: Grant Edwards <grant.b.edwards at gmail.com>
Subject: Re: How to create a socket.socket() object from a socket fd?
References: <o60naq$bbm$1 at blaine.gmane.org> <o60o2r$6cd$1 at blaine.gmane.org> <c7e3116f-6e9c-5343-6f82-c491fb917800 at python.org>
Followup-To: 

<rant>

I'm still baffled why the standard library fromfd() code dup()s the
descriptor.

According to the comment in the CPython sources, the author of
fromfd() is guessing that the user wants to be able to close the
descriptor separately from the socket.

If the user wanted the socket object to use a duplicate descriptor for
some reason, the caller should call os.dup() -- it's only _eight_
keystrokes.  Eight keystrokes that makes it obvious to anybody reading
the code that there are now two descriptors and you have to close both
the original descriptor and the socket.

When you create a Python file object from a file descriptor using
os.fdopen(), does it dup the descriptor?  No.  Would a reasonable
person expect socket.fromfd() to duplicate the descriptor?  No.

Should it?

No.

I know... that particular mistake is set in stone now, and it's not
going to change.  But I feel better.  :)


     $ python
     Python 2.7.12 (default, Dec  6 2016, 23:41:51) 
     [GCC 4.9.3] on linux2
     Type "help", "copyright", "credits" or "license" for more information.
     >>> import this
     The Zen of Python, by Tim Peters
     
     Beautiful is better than ugly.
**** Explicit is better than implicit.
     Simple is better than complex.
     Complex is better than complicated.
     Flat is better than nested.
     Sparse is better than dense.
**** Readability counts.
     Special cases aren't special enough to break the rules.
     Although practicality beats purity.
     Errors should never pass silently.
     Unless explicitly silenced.
**** In the face of ambiguity, refuse the temptation to guess.
     There should be one-- and preferably only one --obvious way to do it.
     Although that way may not be obvious at first unless you're Dutch.
     Now is better than never.
     Although never is often better than *right* now.
     If the implementation is hard to explain, it's a bad idea.
     If the implementation is easy to explain, it may be a good idea.
     Namespaces are one honking great idea -- let's do more of those!

</rant>