IPv4 operations may fail on IPv6 systems, and vice versa. So we have to create sockets with the proper address family.

Maybe this behaviour could be incapsulated in socket object, but didn't find a good way to do it.

No documentation changed, because I just eliminate lack of implementation of already documented feature.

Please help to write tests.

I worked on the 3.2 branch, because the default branch has broken test_logging.

More correct description: IPv4 operations may fail on IPv6 systems, and vice versa; so we have to detect the proper address family before creating a socket.

For TCP, socket.create_connection() is your friend. For UDP I'm not sure, but adding a helper to the socket module might also be a good idea.

The Linux getaddrinfo() man page has an UDP client example which uses connect() to decide whether the target address is valid or not.

Apparently, connecting the socket is better because some systems (BSDs in particular) only report ICMP errors to connected UDP sockets. The Linux man page claims that this reporting is necessary regardless of whether the socket is connected.

I wonder what will happen under this patch if the server has both v4 and v6 connectivity, and the client supports v6, but has no connectivity (other than, say, on the local link).

On my computer, connect() on a UDP socket always finishes successfully. What's wrong?

I tried that C example from man getaddrinfo(3).

> On my computer, connect() on a UDP socket always finishes
> successfully. What's wrong?

Nothing wrong I guess, since connect() on an UDP socket doesn't actually
do anything, network-wise (UDP being an unconnected protocol).

> On my computer, connect() on a UDP socket always finishes  
> successfully. What's wrong?

Nothing is wrong. UDP is connection-less, so connect() is a no-op,
except that it remembers the address so you can use send() instead
of sendto(). Any errors due to non-reachability will only happen when
you actually try to send.

> I worked on the 3.2 branch, because the default branch has broken
> test_logging.

What breakage are you referring to? There's a race condition test that fails on Windows sometimes, but that's on the 2.7 branch. Apart from that, I don't know what breakage you're referring to, so please elaborate.

Can the datagramHandler.host change during execution? If so, the address family of the socket can change. So, we should create a socket for every new message. Check my patch #2.

Also I extended socket.create_connection to support UDP.

test_logging is not broken, but just fails.

test test_logging failed -- Traceback (most recent call last):
  File "/home/cblp/my/cpython_default/Lib/test/test_logging.py", line 2903, in test_time
    self.assertEqual(f.formatTime(r), '1993-04-21 08:03:00,123')
AssertionError: '1993-04-21 09:03:00,123' != '1993-04-21 08:03:00,123'
- 1993-04-21 09:03:00,123
?             ^
+ 1993-04-21 08:03:00,123
?             ^

Or should it go to the separate ticket?

> Or should it go to the separate ticket?

Yes, please.

The datagram handler seems still not useable with IPv6 in Python 3.4. Is this patch still under consideration ?