This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Supply dual-stack (IPv4/IPv6) socket bind routine
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution: duplicate
Dependencies: Superseder: Add socket.bind_socket() convenience function
View: 17561
Assigned To: Nosy List: gregory.p.smith, jaraco, jleedev, pitrou, r.david.murray
Priority: normal Keywords: patch

Created on 2015-11-19 13:32 by jaraco, last changed 2022-04-11 14:58 by admin.

Pull Requests
URL Status Linked Edit
PR 17851 merged jaraco, 2020-01-06 02:11
Messages (5)
msg254895 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2015-11-19 13:32
When binding to a socket for creating a service, the socket API provides a mechanism for selecting only IPv4 or IPv6, but the simple operation of binding to all interfaces in a dual-stack environment is not easy, as is revealed in issue20215 and issue24209, but also in third-party packages. I ran into this during the implementation of aiosmtpd (https://gitlab.com/python-smtpd-hackers/aiosmtpd). As a long time maintainer of CherryPy, I've enjoyed the [dual stack support](https://bitbucket.org/cherrypy/cherrypy/src/536a9cb66e91de92502e766b2b0cf53d1cb5cb4a/cherrypy/wsgiserver/wsgiserver2.py?at=default&fileviewer=file-view-default#wsgiserver2.py-2007:2020) there.

I propose the Python stdlib provide a routine to facilitate this need more generally, and then invoke that implementation to address these other use-cases.

As it is a new feature, a backports package should be created to supply the same functionality for older Pythons.

Would this effort require a PEP? Is there a good place for such a routine (maybe socketserver)? Any other thoughts?
msg254900 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-11-19 14:52
I don't think it should require a PEP, it looks like a fairly straightforward small enhancement.  What is the reason to not put it in the socket module?
msg261317 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2016-03-07 22:38
No reason not to put it in the socket module. I was thinking originally that the socket module was C only, but on further reflection, it could easily be one of the "additional facilities implemented in Python". Great suggestion.
msg286354 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-01-27 13:12
Related though with a different strategy: Tornado's bind_sockets() routine:
https://github.com/tornadoweb/tornado/blob/master/tornado/netutil.py#L114-L138
msg331942 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2018-12-17 01:39
I believe this issue is a duplicate of 17561, which I stumbled onto today.
History
Date User Action Args
2022-04-11 14:58:24adminsetgithub: 69853
2020-01-06 02:11:41jaracosetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request17273
2018-12-17 01:39:39jaracosetsuperseder: Add socket.bind_socket() convenience function
resolution: duplicate
messages: + msg331942
2017-01-27 13:12:17pitrousetmessages: + msg286354
2017-01-27 13:10:32pitrousetnosy: + pitrou
2017-01-26 23:45:31pitrousetversions: + Python 3.7, - Python 3.6
2017-01-25 22:21:17gregory.p.smithsetnosy: + gregory.p.smith
2016-03-07 22:38:54jaracosetmessages: + msg261317
2016-03-07 22:31:12jleedevsetnosy: + jleedev
2015-11-19 14:52:32r.david.murraysetnosy: + r.david.murray
messages: + msg254900

type: enhancement
stage: needs patch
2015-11-19 13:32:53jaracocreate