Whenever Python is compiled with --disable-ipv6, but running on a system that supports ipv6, we observe:

import socket
for info in socket.getaddrinfo("localhost", 12345, 0, socket.SOCK_STREAM):
   print(info)

resulting in:

(<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, 6, '', (10, b'\x94\xa1\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'))
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('127.0.0.1', 38049))

The first type is the raw result coming from the system getaddrinfo implementation: tuple[int, int, int, str, tuple[int, bytes], currently not supported.

Now according to:

• https://bugs.python.org/issue7735
• https://bugs.python.org/issue16208

The correctness of the getaddrinfo return value is debated under the --disable-ipv6 flag. Python has marked both issues as won't fix, a long time ago.

I'm creating this issue to debate the value of adding a new return type variant to getaddrinfo. The likelihood of this happening is small, as Python usually ships with ipv6 support. However, it could result in library owners not correctly handling the return values.