Commit 540a9c69c2ea introduced double assertRaises which now is failing on ubuntu 16.10

If it is necessary, then it's not obvious why and there is no comment, but here is the one-line patch that removes the duplicated line and makes the test pass for me.

That’s not exactly a duplicate; one is host-by-NAME, the other host-by-ADDR

It might be interesting to stick a 'with subtest' in there and see which address is failing to raise.

Of course, you're right, that was my mistake. The last three addresses fail to raise, namely: '::1q', '::1::2' and '1:1:1:1:1:1:1:1:1'.

Hi SilentGhost. I'm also using Ubuntu 16.10 but the test case doesn't fail.

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.10
DISTRIB_CODENAME=yakkety
DISTRIB_DESCRIPTION="Ubuntu 16.10"

./python -Wa -m test -v test_socket | grep test_host_resolution
test_host_resolution (test.test_socket.GeneralModuleTests) ... ok

Maybe worth looking at what name resolution stuff is enabled in /etc/nsswitch.conf. On the hosts line, my current computer (v basic setup) has

hosts: files dns myhostname

My guess is you have a plugin which is resolving these ip-address lookalikes.

> My guess is you have a plugin which is resolving these ip-address lookalikes.

That probably is the reason. My hosts line looks like:

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

I guess there isn't much that could be done on Python side then and we can close the issue?

> hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

I think this is the default config. Same as mine. Does test_host_resolution still stably fails?

> Does test_host_resolution still stably fails?

Yes.

I’m curious what the result of gethostbyaddr() is in your case, Silent Ghost.

import socket
socket.gethostbyaddr("::1q")
socket.gethostbyaddr("::1::2")
socket.gethostbyaddr("1:1:1:1:1:1:1:1:1")

On my computer, I get “socket.gaierror: [Errno -2] Name or service not known” from each call.

Perhaps this is similar to the problems encountered with test_bad_address() at Lib/test/test_urllibnet.py:102

I get either ('ec2-54-88-107-140.compute-1.amazonaws.com', [], ['54.88.107.140']) or ('ec2-54-84-80-173.compute-1.amazonaws.com', [], ['54.84.80.173']).

It indeed seems to be related to ISP, as I get a regular socket.gaierror raised when I try this on another machine with a different provider. Naturally, it's not related to either 3.6 or 3.7, as I get the same behaviour even with 3.5.

Skipping test might be an option, but one would probably need to wrap all uses of gethostbyaddr into a test helper?

The three ipv6 addresses are all invalid addresses if we conform to spec.

"::1q"              non hex characteres
"::1::2"            two "::" but at most one is allowed
"1:1:1:1:1:1:1:1:1" 144 bits > 128 bits

> Perhaps this is similar to the problems encountered with test_bad_address() at Lib/test/test_urllibnet.py:102

I think they are the similar situations.

Maybe you could factor out the first part of test_bad_address() that skips the test. It would only need to be used by negative test cases (that purposefully test invalid names). I presume positive tests would not need to be wrapped.

I think the original test is trying to ensure that an invalid numeric IP address results in an OSError. So changing it to skip the test on OSError does not seem wise. Also, Silent Ghost said that the problem was with gethostbyaddr(), not gethostbyname().

I was wondering if there was a separate way to detect the troublesome ISP environment, e.g. trying gethostbyname(bogus_domain).

Ohh, sorry.

> I was wondering if there was a separate way to detect the troublesome ISP environment.

How could you differentiate the failure between ISP environment caused and function behaved wrongly? Successfully resolve an invalid ip address doesn't mean you can successfully resolve a bogus domain.

I think this case should be rare. Maybe we can just fail the test and warn the user this failure is not 100% caused by function's misbehaviour, just like test_bad_address.

New changeset 284a2ba140cf11216e9804573d8cea6674ab90d9 by Xiang Zhang in branch '3.6':
bpo-28728: clarify possible test failure due to ISP (GH-412) (GH-531)
https://github.com/python/cpython/commit/284a2ba140cf11216e9804573d8cea6674ab90d9

New changeset d36a71637cefdddc02efd884f1b2c204f370afaa by Xiang Zhang in branch 'master':
bpo-28728: clarify possible test failure due to ISP (GH-412)
https://github.com/python/cpython/commit/d36a71637cefdddc02efd884f1b2c204f370afaa