Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23374
___
Roundup Robot added the comment:
New changeset e7b6b1f57268 by Serhiy Storchaka in branch '3.4':
Issue #23374: Fixed pydoc failure with non-ASCII files when stdout encoding
https://hg.python.org/cpython/rev/e7b6b1f57268
New changeset affe167a45f3 by Serhiy Storchaka in branch 'default':
Issue
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23374
___
___
Serhiy Storchaka added the comment:
Added a test.
--
Added file: http://bugs.python.org/file38146/pydoc_encoding_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23374
___
Martin Panter added the comment:
Patch looks sensible to me. This is another example of where Issue 15216 would
be useful (a standard way to modify the encoding settings of a stream).
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
In the case of this issue pydoc needs change not the encoding of stdout, but
errors handler of stdout. There is similar issue with pprint (issue19100).
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
There are few levels of this issue:
1) pydoc doesn't escape characters according to output encoding. It escapes
characters uneencodable with sys.getfilesystemencoding(), but this encoding can
differ from the encoding of sys.stdout or default encoding.
2)
New submission from Skip Montanaro:
I'm probably doing something wrong, but I've tried everything I can think of
without any success.
In Python 2.7, the pydoc command successfully displays help for the sqlite3
package, though it muffs the output of Gerhard Häring's name, spitting out
the
Skip Montanaro added the comment:
On Sun, Feb 1, 2015 at 2:19 PM, Skip Montanaro rep...@bugs.python.org wrote:
The issue is that I didn't
mix my case properly when setting LANG:
Actually, it's that the hyphen is required in utf-8 or UTF-8.
--
___
Martin Panter added the comment:
Maybe because a pager sends its bytes more-or-less straight throught from input
to output, the PYTHONIOENCODING (sys.stdout.encoding?) should be used for the
TextIOWrapper to the pager’s input in this case. I’m not so sure this should be
assumed in general
Skip Montanaro added the comment:
Without setting any environment variables:
import sys
sys.getfilesystemencoding()
'utf-8'
import locale
locale.getpreferredencoding(False)
'US-ASCII'
import os
os.popen('cat', 'w').encoding
'US-ASCII'
If I set PYTHONIOENCODING=UTF-8:
import sys,
Serhiy Storchaka added the comment:
What are sys.getfilesystemencoding(), locale.getpreferredencoding(False),
os.popen('cat', 'w').encoding?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23374
Skip Montanaro added the comment:
Peter Otten posted a solution on c.l.py. The issue is that I didn't
mix my case properly when setting LANG:
hgpython% LANG=en_US.UTF-8 python3.5 -c 'import locale;
print(locale.getpreferredencoding(False))'
UTF-8
hgpython% LANG=en_US.utf8 python3.5 -c 'import
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23374
___
___
Skip Montanaro added the comment:
Final note here. Peter also did a bit of digging. Here's his note about
what he found on c.l.py:
The pager is invoked by os.popen(), and after some digging I find that it
uses a io.TestIOWrapper() to write the help text. This in turn uses
15 matches
Mail list logo
