The problem is that there are several places in the test suite (and the stdlib itself!) that assume that 127.0.0.1 is a valid loopback address.  This is the de-facto Internet standard, and while I know not all systems make 127.0.0.1 a valid loopback and/or do not map localhost to it, I'm not sure this is something it is practical for the stdlib or the test suite to compensate for.  (I had this problem with linux-vserver on my buildbots, see issue 3972).  It is true that the test suite in in a couple places assumes that 'localhost' maps to 127.0.0.1, which is an assumption that breaks more often than that of 127.0.0.;1 being a a valid loopback, since it depends on the "correct" configuration of the local host.

We've got a catch 22: if we assume localhost maps to a valid loopback address, the tests will fail on systems that are not configured correctly, while if we assume that 127.0.0.1 is a valid loopback address but may not be 'localhost', the tests will fail on systems for which 127.0.0.1 is not a valid loopback.  Since the stdlib itself assumes that 127.0.0.1 is valid, the former wins.  (As far as I know we don't have any open issues against the stdlib for this assumption.  If it is problematic on your system, then you should open a separate issue about that so we can consider it.)

If this test fails on your system because 127.0.0.1 is not a loopback address, I would expect many other tests to fail as well (ex: test_ssl).  If they do not, then I suspect your real problem is that localhost doesn't map to 127.0.0.1 even though 127.0.0.1 is a valid loopback address.  So, it looks to me like the better "fix" here would be to change 'URL' to be 'http://127.0.0.1'.  Can you confirm if that works for you, please?