Would it be possible to create a PyPI project to experiement the API and wait until we collected enough user feedback first? Currently socket is low level. Not sure if I like the idea of putting more high level features in it? Asyncio is a good place for high level features, but is limited to async programming. Victor Le 5 mars 2017 12:46, "Giampaolo Rodola'" <g.rodola@gmail.com> a écrit :

Some years ago I started working on a patch for the socket module which added a couple of utility functions for being able to easily create a server socket, with the addition of being able to accept both IPv4 and IPv6 connections (as a single socket): https://bugs.python.org/issue17561

Given that not all OSes (Windows, many UNIXes) support this natively, I later submitted a recipe adding a "multiple socket listener" class. https://code.activestate.com/recipes/578504-server- supporting-ipv4-and-ipv6/

From the user perspective, the whole thing can be summarized as follows:

...

...

...

sock = create_server_sock(("", 8000)) if not has_dual_stack(sock): ... sock.close() ... sock = MultipleSocketsListener([("0.0.0.0", 8000), ("::", 8000)])

Part of this work ended up being included into Tulip internals: https://github.com/python/cpython/blob/70d28a184c42d107cc8c69a95aa52a 4469e7929c/Lib/asyncio/base_events.py#L966-L1067 ...and after that I basically forgot about the original patch. The other day I bumped into a case where I needed exactly this (on Windows), so here I am, trying to revamp the original proposal.

To be clear, the proposal is to add 3 new APIs in order to avoid the low-level cruft needed when creating a server socket (SO_REUSEADDR, getaddrinfo() etc.) and being able to support IPv4/6 dual-stack socket servers in a cross-platform fashion:

- socket.has_dual_stack() - socket.create_server_sock() - socket.MultipleSocketsListener

Whereas the first two functions are relatively straightforward, MultipleSocketsListener is more debatable because, for instance, it's not clear what methods like getsockname() should return (because there are 2 sockets involved). One possible solution is to *not* expose such (all get*?) methods and simply expose the underlying socket objects as in:

...

...

...

socket.MultipleSocketsListener(...).socks[0].getsockname()

On the other hand, all set* / write methods (setblocking(), setsockopt(), shutdown(), ...) can be exposed and internally they can simply operate against both sockets.

Thoughts?

-- Giampaolo - http://grodola.blogspot.com

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Would it be possible to create a PyPI project to experiement the API and wait until we collected enough user feedback first? Currently socket is low level. Not sure if I like the idea of putting more high level features in it? Asyncio is a good place for high level features, but is limited to async programming. Victor Le 5 mars 2017 12:46, "Giampaolo Rodola'" <g.rodola@gmail.com> a écrit :

Some years ago I started working on a patch for the socket module which added a couple of utility functions for being able to easily create a server socket, with the addition of being able to accept both IPv4 and IPv6 connections (as a single socket): https://bugs.python.org/issue17561

Given that not all OSes (Windows, many UNIXes) support this natively, I later submitted a recipe adding a "multiple socket listener" class. https://code.activestate.com/recipes/578504-server- supporting-ipv4-and-ipv6/

From the user perspective, the whole thing can be summarized as follows:

...

...

...

sock = create_server_sock(("", 8000)) if not has_dual_stack(sock): ... sock.close() ... sock = MultipleSocketsListener([("0.0.0.0", 8000), ("::", 8000)])

Part of this work ended up being included into Tulip internals: https://github.com/python/cpython/blob/70d28a184c42d107cc8c69a95aa52a 4469e7929c/Lib/asyncio/base_events.py#L966-L1067 ...and after that I basically forgot about the original patch. The other day I bumped into a case where I needed exactly this (on Windows), so here I am, trying to revamp the original proposal.

To be clear, the proposal is to add 3 new APIs in order to avoid the low-level cruft needed when creating a server socket (SO_REUSEADDR, getaddrinfo() etc.) and being able to support IPv4/6 dual-stack socket servers in a cross-platform fashion:

- socket.has_dual_stack() - socket.create_server_sock() - socket.MultipleSocketsListener

Whereas the first two functions are relatively straightforward, MultipleSocketsListener is more debatable because, for instance, it's not clear what methods like getsockname() should return (because there are 2 sockets involved). One possible solution is to *not* expose such (all get*?) methods and simply expose the underlying socket objects as in:

...

...

...

socket.MultipleSocketsListener(...).socks[0].getsockname()

On the other hand, all set* / write methods (setblocking(), setsockopt(), shutdown(), ...) can be exposed and internally they can simply operate against both sockets.

Thoughts?

-- Giampaolo - http://grodola.blogspot.com

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/