According to "pydoc --help", pydoc -p Start an HTTP server on the given port on the local machine. The IP address pydoc binds to is not specified, thus I would expect it to either bind to the local address or to the wildcard address. Current behaviour of "pydoc -p 1234" is to bind to the IPv4-only address 0.0.0.0:1234. On a IPv4/IPv6 dual-stack machine, I would expect pydoc to listen to either both 127.0.0.1:1234 and [::1]:, or just [::]: ([::] also catches accesses to IPv4 addresses such as 127.0.0.1). Then access to the pydoc webserver is available both via IPv4 (e.g. http://127.0.0.1:1234/) and IPv6 (e.g. http://[::1]:1234/), and in both cases via http://localhost:1234/ regardless whether localhost is resolved via IPv6 or IPv4. Trivial patch attached (tested on Linux x86 machine with local IPv6 networking).
That will break on systems where AF_INET6 doesn't default to dual-stacked sockets and mapped v4 addresses (e.g. Windows); to make it work correctly, you'll also have to disable the IPV6_V6ONLY option, which then breaks on systems which don't implement that option (e.g. Windows XP).
Currently pydoc only binds to IPv4 localhost, not the “any-address” 0.0.0.0. See Issue 22421 and Issue 672656. Apart from satisfying Hans’s expectation, what is the benefit of running pydoc on IPv6? I guess it would be possible to bind two sockets, one to IPv4 localhost (127.1 or ::ffff:127.0.0.1), and the other IPv6 localhost (::1). But why bother?
