[Patches] [ python-Patches-1364545 ] test_cmd_line expecting English error messages
SourceForge.net
noreply at sourceforge.net
Fri Nov 25 18:02:55 CET 2005
Patches item #1364545, was opened at 2005-11-23 12:01
Message generated for change (Settings changed) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tests
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A.B., Khalid (abkhd)
>Assigned to: Nobody/Anonymous (nobody)
Summary: test_cmd_line expecting English error messages
Initial Comment:
Currently test_directories of test_cmd_line fails on
the latest Python 2.4.2 from svn branch and from the
svn head. The reason it seems is that the test assumes
that the local language of Windows is English and so
tries to find the string " denied" in the returned
system error messages of the commands ("python .") and
("python < .").
But while it is true that the first command ("python
.") does return an English string error message even on
so-called non-English versions of Windows, the same
does not seem to be true for the second command
("python < ."), which seems to return a locale-related
string error message. And since the latter test is
looking for the English " denied" in a non-English
language formated string, the test fails in non-English
versions of Windows.
Walter asked me to post the patch here, and assign it
to him. The patch uses subprocess and uses exitcodes
for testing. I tested the patch successfully, but only
on Windows. Although subprocess is supposed to work on
all platforms, someone'd better test this just to be
sure. I don't know what the policy for backporting is.
But if allowed, this should be backported to Python
2.4.2 at least.
----------------------------------------------------------------------
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-25 18:02
Message:
Logged In: YES
user_id=89016
Checked in a variant of abkhd's patch as r41541 and r41542.
Thanks for the patch.
----------------------------------------------------------------------
Comment By: A.B., Khalid (abkhd)
Date: 2005-11-23 17:56
Message:
Logged In: YES
user_id=1079026
Forgot to say the patch is attached.
----------------------------------------------------------------------
Comment By: A.B., Khalid (abkhd)
Date: 2005-11-23 17:53
Message:
Logged In: YES
user_id=1079026
Well we seem to have two problems here. The first is the one
you changed subprocess' call arguments to avoid as it seems
Windows/Linux or subprocess deal with string arguments
differently.
The second, which is more serious in my view, is how "python
." yeilds an error on Windows, but no error at all on Linux.
If other platform behave the same then why is there a need
for this test? If the difference is just between these two
platforms then I think we can manage with hardcoding the
exit codes. Ugly, yes. But it works.
#-------------------------
# On Windows
#-------------------------
$ python -i
Python 2.5a0 (#66, Nov 22 2005, 23:25:46)
[GCC 3.4.2 (mingw-special)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import test_cmd_line as t
>>> t.test_main()
test_directories (test_cmd_line.CmdLineTest) ... ok
test_environment (test_cmd_line.CmdLineTest) ... ok
test_optimize (test_cmd_line.CmdLineTest) ... ok
test_q (test_cmd_line.CmdLineTest) ... ok
test_site_flag (test_cmd_line.CmdLineTest) ... ok
test_usage (test_cmd_line.CmdLineTest) ... ok
test_version (test_cmd_line.CmdLineTest) ... ok
----------------------------------------------------------------------
Ran 7 tests in 6.750s
OK
>>>
#-------------------------
# On Linux
#-------------------------
ubuntu at ubuntu:~/Desktop$ python
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import test_cmd_line as t
>>> t.test_main()
test_directories (test_cmd_line.CmdLineTest) ... ok
test_environment (test_cmd_line.CmdLineTest) ... ok
test_optimize (test_cmd_line.CmdLineTest) ... ok
test_q (test_cmd_line.CmdLineTest) ... ok
test_site_flag (test_cmd_line.CmdLineTest) ... ok
test_usage (test_cmd_line.CmdLineTest) ... ok
test_version (test_cmd_line.CmdLineTest) ... ok
----------------------------------------------------------------------
Ran 7 tests in 1.701s
OK
>>>
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2005-11-23 13:28
Message:
Logged In: YES
user_id=89016
The test doesn't work on Linux. I get:
Traceback (most recent call last):
File "Lib/test/test_cmd_line.py", line 19, in test_directories
self.assertTrue(self.exit_code('.') != 0)
File "Lib/test/test_cmd_line.py", line 16, in exit_code
return subprocess.call("%s %s" % (sys.executable,
cmd_line), stderr=subprocess.PIPE)
File
"/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py",
line 431, in call
return Popen(*popenargs, **kwargs).wait()
File
"/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py",
line 580, in __init__
errread, errwrite)
File
"/var/home/walter/Python-checkouts/Python-unittest/Lib/subprocess.py",
line 1033, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Changing
call("%s %s" % (sys.executable, cmd_line), stderr=PIPE)
to
call([sys.executable, cmd_line], stderr=PIPE)
leads to
Traceback (most recent call last):
File "Lib/test/test_cmd_line.py", line 22, in test_directories
self.assertTrue(self.exit_code('.') != 0)
AssertionError
Is there anything else I can try?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1364545&group_id=5470
More information about the Patches
mailing list