Ned Deily added the comment:
I don't disagree that it would be better to have an error-free test run,
independent of the ISP in use. You could try using a different DNS server that
behaves as expected (search the web for lists of free and public DNS servers).
Otherwise, you could try to re-o
Steve P added the comment:
I saw that issue, or one like it. I was very tempted to not report but
the README says if there are any test failures, there is a problem. (I
suppose it could mean there is a problem with my ISP, not python.) The
dilemma is that we want to be able to count on a c
Ned Deily added the comment:
Thanks for the additional information. It appears this is a duplicate of
Issue17564 with the root cause being the ISP not properly rejecting an
undefined host name as expected by the test case. See the discussion there for
more information.
--
resolution
Steve P added the comment:
I got "test_bad_address" from what was reported using "make test". Perhaps
at I read the log wrong, but it was clear I got a failure. At any rate,
here's what I get with the correct test name:
sp@chip:~/Downloads/Python-3.4.2 $ ./python -m test -v -u network
> test_u
Ned Deily added the comment:
I'm not sure what you are trying to do but there is no test module named
test_bad_address in the standard library, which is why you get that error.
Doing a quick search of Lib/test shows three different cases of
test_bad_address: in the test_ipaddress, test_urllib
New submission from Steve P:
Looking in past bug reports, I suspect the test itself is problematic. When I
paste the (erroneous) URL the tests is using into Firefox, I get a page back
from my ISP with "Sorry, the website sadflkjsasf.i.nvali.d cannot be found"
Here's the output of the test:
@c
