Some ftplib tests sometimes time out. Seem they seem to try to connect to "localhost" (rather than "127.0.0.1"), I was wondering if this could be a DNS issue and if we should resolve "localhost" in advance like Charles-François did for some other tests (or simply hardcode "127.0.0.1", actually).

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7060/steps/test/logs/stdio

(example:

======================================================================
ERROR: testTimeoutDefault (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 953, in testTimeoutDefault
    ftp = ftplib.FTP("localhost")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 115, in __init__
    self.connect(host)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 150, in connect
    source_address=self.source_address)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 454, in create_connection
    raise err
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 445, in create_connection
    sock.connect(sa)
socket.timeout: timed out

)

Some ftplib tests sometimes time out. Seem they seem to try to connect to "localhost" (rather than "127.0.0.1"), I was wondering if this could be a DNS issue and if we should resolve "localhost" in advance like Charles-François did for some other tests (or simply hardcode "127.0.0.1", actually).

If it only happens on Windows >= 7 buildbots, then it's likely a
consequence of this:
http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

Apparently, since Windows 7, "localhost" doesn't appear in the hosts
file anymore: so, depending on your DNS resolver settings, this could
perfectly explain such timeouts (assuming it's not a firewall issue).

Hard-cording 127.0.0.1 for this test should be OK, because the server
setup explicitly binds an AF_INET socket. We'll probably have to check
the rest of the test suite for similar issues.

Hard-cording 127.0.0.1 for this test should be OK, because the server
setup explicitly binds an AF_INET socket. We'll probably have to check
the rest of the test suite for similar issues.

Ok, let's do it!

Here is a patch for default.

Changing support.HOST from 'localhost' to '127.0.0.1' means that on dual-stack
hosts (I don't think the test suite would run on IPv6-only hosts anyway), the
tests will now always use IPv4, whereas they are currently using either IPv6 or
IPv4 addresses depending on the host's name resolution settings.
For example, on a RHEL6 box:

>>> socket.getaddrinfo('localhost', 0)
[(10, 1, 6, '', ('::1', 0, 0, 0)), (10, 2, 17, '', ('::1', 0, 0, 0)),
(10, 3, 0, '', ('::1', 0, 0, 0)), (2, 1, 6, '', ('127.0.0.1', 0)), (2,
2, 17, '', ('127.0.0.1', 0)), (2, 3, 0, '', ('127.0.0.1', 0))]

So on this host, 'localhost' resolves to '::1'. I think it would be
better to have support.HOST set to socket.getaddrinfo('localhost', 0)[0][4][0]
(sic), so that the test will use the preferred protocol on the target host, and
also that IPv6 is also tested in tests which don't explicitely use
'::1'. But this
means that we should have an support.HOSTv4 for tests that explicitly rely on
IPv4, e.g. test_ftplib.

Changing support.HOST from 'localhost' to '127.0.0.1' means that on
dual-stack
hosts (I don't think the test suite would run on IPv6-only hosts
anyway), the
tests will now always use IPv4, whereas they are currently using
either IPv6 or
IPv4 addresses depending on the host's name resolution settings.

That would only be true if the server we are contacting happens to
listen on both IPv6 and IPv4, right? I don't think we have such a
situation in the test suite. Clients can use create_connection()
for transparent support of IPv6 and IPv4, but servers have to choose
a family when creating their socket.

That would only be true if the server we are contacting happens to
listen on both IPv6 and IPv4, right? I don't think we have such a
situation in the test suite.

Ah, I thought some code was using getaddrinfo() to select an arbitrary
bind() address for localhost.

That's OK then.

LGTM

New changeset 085ba7d85eb2 by Antoine Pitrou in branch 'default':
Issue bpo-18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/085ba7d85eb2

New changeset 7728b073c77c by Antoine Pitrou in branch '3.3':
Issue bpo-18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/7728b073c77c

New changeset 48de8df194d9 by Antoine Pitrou in branch '2.7':
Issue bpo-18792: Use "127.0.0.1" or "::1" instead of "localhost" as much as possible, since "localhost" goes through a DNS lookup under recent Windows versions.
http://hg.python.org/cpython/rev/48de8df194d9

Done, thanks :)

FYI - hardcoding these addresses is now causing me problems as I try to get our test suite passing on IPv6 only hosts. "localhost" is correct.

IMNSHO if for some reason a system cannot resolve "localhost" into a correct address, it should be banned from running any form of networking related test. :/

I should not have to write messy conditional code to try and determine which type of socket I will likely need to bind to to determine which format of IP address string I need to supply as the localhost bind address. That is backwards!

https://bugs.python.org/issue29639 opened to track undoing this when appropriate.