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.rod...@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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
