test_sys failures
When I build from scratch and run most tests (regrtest.py -uall) I get some strange failures with test_sys.py: test test_sys failed -- Traceback (most recent call last): File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", line 302, in test_43581 self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) AssertionError: 'ascii' != 'ISO-8859-1' The same test doesn't fail when run in isolation. Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6! Any ideas? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
I am unable to reproduce this in windows with: Python 3.0a2 (py3k:59584M, Dec 20 2007, 16:24:12) [MSC v.1500 32 bit (Intel)] on win32 Running the test via rt and in isolation does not appear to fail. In isolation produces 16 OKs. Joe On Dec 20, 2007 3:58 PM, Guido van Rossum <guido@python.org> wrote:
When I build from scratch and run most tests (regrtest.py -uall) I get some strange failures with test_sys.py:
test test_sys failed -- Traceback (most recent call last): File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", line 302, in test_43581 self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) AssertionError: 'ascii' != 'ISO-8859-1'
The same test doesn't fail when run in isolation.
Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6!
Any ideas?
-- --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/> ) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.c...
Guido van Rossum wrote:
When I build from scratch and run most tests (regrtest.py -uall) I get some strange failures with test_sys.py:
test test_sys failed -- Traceback (most recent call last): File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", line 302, in test_43581 self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) AssertionError: 'ascii' != 'ISO-8859-1'
The same test doesn't fail when run in isolation.
Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6!
Any ideas?
It looks like the chunk of code in TextIOWrapper might be getting different answers when trying to work out the encoding for stdin and stderr (not that I can see how that would happen...). Or maybe there is some way that test_sys could be seeing the temporary '__stderr__' entry that is put in place until the io module is available? What do you get for stdin/stdout/stderr.encoding at the interactive prompt? On Ubuntu, I get UTF-8 for all of them in both 3.0a2 and 2.5.1, but I'm not seeing the problem, either. Other values of possible interest: os.device_encoding(1) os.device_encoding(2) locale.getpreferredencoding() Another possibility would be to throw some debugging code into io.py to print out the encoding name to stderr when file is 1 or 2. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
On Dec 21, 2007 12:05 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Guido van Rossum wrote:
When I build from scratch and run most tests (regrtest.py -uall) I get some strange failures with test_sys.py:
test test_sys failed -- Traceback (most recent call last): File "/usr/local/google/home/guido/python/py3kd/Lib/test/test_sys.py", line 302, in test_43581 self.assertEqual(sys.__stdout__.encoding, sys.__stderr__.encoding) AssertionError: 'ascii' != 'ISO-8859-1'
The same test doesn't fail when run in isolation.
Interestingly, I saw this with 2.5 as well as 3.0, but not with 2.6!
Any ideas?
It looks like the chunk of code in TextIOWrapper might be getting different answers when trying to work out the encoding for stdin and stderr (not that I can see how that would happen...). Or maybe there is some way that test_sys could be seeing the temporary '__stderr__' entry that is put in place until the io module is available?
What do you get for stdin/stdout/stderr.encoding at the interactive prompt? On Ubuntu, I get UTF-8 for all of them in both 3.0a2 and 2.5.1, but I'm not seeing the problem, either.
Other values of possible interest: os.device_encoding(1) os.device_encoding(2) locale.getpreferredencoding()
Another possibility would be to throw some debugging code into io.py to print out the encoding name to stderr when file is 1 or 2.
No answers yet, but a clue, and anyone on OSX should now be able to reproduce this (with 2.5, 2.6 or 3.0) as follows: ./python ./Lib/test/test_sys.py | cat That is, the problem happens when stdout is redirected to a pipe (or a file). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
No answers yet, but a clue, and anyone on OSX should now be able to reproduce this (with 2.5, 2.6 or 3.0) as follows:
./python ./Lib/test/test_sys.py | cat
That is, the problem happens when stdout is redirected to a pipe (or a file).
Redirecting stdout also fails for both the trunk and the py3k branch for me on Ubuntu. If I redirected stderr as well then the tests worked again. Given that a pipe/file and the console very likely *do* have different encodings, maybe the test is just wrong? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
-On [20080108 12:09], Nick Coghlan (ncoghlan@gmail.com) wrote:
Redirecting stdout also fails for both the trunk and the py3k branch for me on Ubuntu. If I redirected stderr as well then the tests worked again.
Given that a pipe/file and the console very likely *do* have different encodings, maybe the test is just wrong?
This sounds like a problem I recently blogged about (verbatim copy): When you use Python with sys.stdout you might run into a problem where sys.stdout.encoding suddenly becomes None. This happens due to the fact that upon using a pipe or redirection, at least under Unix, it falls back to not knowing anything about the target. In order to work around this you can add a fallback to use locale.getpreferredencoding(). So if you use encode() on a string you can do something like: from locale import getpreferredencoding text = u"Something special" print text.encode(sys.stdout.encoding or getpreferredencoding() or 'ascii', 'replace') This is how we currently use it within Babel as well for printing the locale list. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Angel to some, Daemon to others...
participants (4)
-
Guido van Rossum -
Jeroen Ruigrok van der Werven -
Joseph Armbruster -
Nick Coghlan