[issue8963] test_urllibnet failure

Senthil Kumaran added the comment: Closing this based on - msg155387. The upstream bug is "unfortunately" closed as OLD. We can reopen if this stumble upon this again. -- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed __

[issue8963] test_urllibnet failure

Ross Lagerwall added the comment: I tested the code from msg107484 on Fedora 16 with no change in locale. Probably OK to close? -- nosy: +rosslagerwall ___ Python tracker ___ __

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: It looks like your libc calls setlocale(LC_ALL, "") on error. This may or may not be right and not python's problem in any case. What is worth to investigate, however is why @run_with_locale decorator fails to restore the locale after it was modified

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: The culprit seems to be test_bad_address. If I disable this test, or replace the bad URL by a good one, everything works fine. It seems that failing to resolve the domain name changes the current locale... -- ___ P

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: Ok, so what it boils down to is the following behaviour: >>> import locale, socket >>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> locale.getlocale(locale.LC_TIME) (None, None) >>> sock.connect(("invalidhost", 80)) Traceback (most recent call l

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: $ ./python.exe -m test.regrtest -unetwork test_urllibnet test_urllibnet 1 test OK. Also the arguments to strptime from reported error message work fine: >>> import time >>> time.strptime('Thu, 10 Jun 2010 19:03:39 GMT', '%a, %d %b %Y %H:%M:%S GMT') time.

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: > What is your locale? $ locale LANG=fr_FR.utf8 LC_CTYPE="fr_FR.utf8" LC_NUMERIC="fr_FR.utf8" LC_TIME="fr_FR.utf8" LC_COLLATE="fr_FR.utf8" LC_MONETARY="fr_FR.utf8" LC_MESSAGES="fr_FR.utf8" LC_PAPER="fr_FR.utf8" LC_NAME="fr_FR.utf8" LC_ADDRESS="fr_FR.utf8" LC_TE

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: Antoine, Would s/LC_TIME/LC_ALL/ in my patch fix your problem? I could not find an affected system, but I simulated the problem by adding locale.setlocale(locale.LC_ALL, "") call in the test. I think the patch is worth applying. It fixes the typo in t

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: > Would s/LC_TIME/LC_ALL/ in my patch fix your problem? As I explained, this wouldn't fix the later failures in test_strptime. -- ___ Python tracker __

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: In setipaddr() in socketmodule.c, the following line appears to change the current locale when DNS lookup fails: error = getaddrinfo(name, NULL, &hints, &res); This is checked by making a call to setlocale(LC_TIME, NULL) before and after the aforemention

[issue8963] test_urllibnet failure

Changes by Antoine Pitrou : -- versions: +Python 2.6, Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: > The patch is not sufficient, since other > failures can then occur if test_strptime gets > run after test_urllibnet This looks like a bug in support.run_with_locale decorator. It is described as #==

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: The patch is not sufficient, since other failures can then occur if test_strptime gets run after test_urllibnet: == ERROR: test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) --

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: I still cannot reproduce the failure, but please, try the attached patch. -- keywords: +patch Added file: http://bugs.python.org/file17608/issue8963.diff ___ Python tracker _

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: Strangely, it also works here from the prompt: >>> import time >>> time.strptime('Thu, 10 Jun 2010 19:03:39 GMT', '%a, %d %b %Y %H:%M:%S GMT') time.struct_time(tm_year=2010, tm_mon=6, tm_mday=10, tm_hour=19, tm_min=3, tm_sec=39, tm_wday=3, tm_yday=161, tm_isds

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: I've reported the bug upstream at Mandriva: https://qa.mandriva.com/show_bug.cgi?id=59736 It would be nice to know whether other distributions with a Redhat lineage are affected. Can someone with such a distribution the code in msg107484? In the end, I'm not

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: What is your locale? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8963] test_urllibnet failure

Antoine Pitrou added the comment: > How do I enable `network' resource? Use the "-unetwork" flag to regrtest. -- ___ Python tracker ___ _

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: How do I enable `network' resource? I am getting $ ./python.exe -m test.regrtest test_urllibnet test_urllibnet test_urllibnet skipped -- Use of the `network' resource not enabled 1 test skipped: test_urllibnet Those skips are all expected on darwin.

[issue8963] test_urllibnet failure

New submission from Antoine Pitrou : This test failure just happened to me on a py3k checkout: test test_urllibnet failed -- Traceback (most recent call last): File "/home/antoine/py3k/debug/Lib/test/test_urllibnet.py", line 191, in test_data_header time.strptime(datevalue, dateformat)

[issue8963] test_urllibnet failure

Martin v. Löwis added the comment: This looks like a glibc bug to me. I suspect an unauthorized redhat change; I hope Ulrich Drepper would have never accepted a glibc that causes getaddrinfo to implicitly call setlocale - see http://sources.redhat.com/ml/libc-alpha/2004-03/msg00161.html You

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: BTW, looking at test_bad_address(), I wonder why it puts extra dots in the url? The comment above it suggests that the intent is to use a name within RFC 2606 .invalid TLD. Not likely to be a problem in your case, but using made up TLD is not a good i