Nikolay, you may want to check out this Python tracker issue.

Giampaolo: I didn't even know it was possible for a single socket to be
dual-stack. (It would seem problematic for UDP recvfrom() for example.) In
Tulip it does indeed make more sense to create separate sockets and just
listen on all of them (using the same protocol factory). This can be
completely transparent to the code calling start_serving() and to the
protocol implementation. So if you're brave you can just send a code review
using codereview.appspot.com to the python-tulip list!

On Mon, Apr 1, 2013 at 1:13 PM, Giampaolo Rodola' <report@bugs.python.org>wrote:

>
> Giampaolo Rodola' added the comment:
>
> Being Tulip asynchronous I think that what it needs is an utility function
> which returns *multiple* sockets as are the addresses returned by
> getaddrinfo() and also possibly even disable the IPv4/6 dual stack in order
> to be consistent across all platforms.
>
> After the sockets are returned they can be "registered" against the event
> loop as two separate entities such as, say, ("0.0.0.0", 8000) *and* ("::",
> 8000).
> If you think this makes sense I can contribute something like this into
> Tulip, or I can bring it up on Tulip's ml and ask for other people's
> opinions.
>
> My current recipe is different in that it provides a function which
> bind()s on one socket only and tries to enable the dual stack whenever
> possible in order to support IPv4 and IPv6 with a single socket.
> In this it is similar to socket.create_connection() and clearly favors
> blocking socket usages (although it can also be used in non-blocking apps)
> which kind of represents the default for the stdlib.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue17561>
> _______________________________________
>