[Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING (original) (raw)
M.-A. Lemburg mal at egenix.com
Tue May 20 10:41:43 CEST 2008
- Previous message: [Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING
- Next message: [Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2008-05-20 10:22, Martin v. Löwis wrote:
I'd like to propose a new environment variable PYTHONSTDOUTENCODING. This is meant to solve various problems that people had with Python not detecting their terminal encoding correctly; it would override any detection that Python would use for determining the encoding of stdout (and stdin - but that's less relevant in 2.x).
How is this relevant for 2.x ?
In 2.x, stdin and stdout are just files without any io wrappers around them.
Writing Unicode to stdout will still use the default encoding ASCII to convert it to an 8-bit string. All other 8-bit strings will be passed to stdout as-is.
For 3.x, I'd like to see a PYTHONSTDINENCODING, because the current way of relying on the terminal encoding does work well... it then falls back to ASCII, which prevents entering e.g. German Umlauts.
In particular, setting this environment variable would also disable the detection of whether stdout is a terminal. This is desirable for cases as the pydev eclipse plugin, where Python currently fails to detect that the output is a terminal (and technically, what Eclipse provides is not a terminal, but just a pipe, as you can't do pseudoterms in Java).
This would have the additional effect that the encoding also gets in effect when redirecting stdout to a file. Whether or not this is a good thing might be debatable; giving the user the control over it (to set or clear that variable) is a good thing, IMO. Naming contest: it probably would be the longest of the PYTHON* variables. I would not want to call it PYTHONENCODING, or PYTHONSTDENCODING, though, because people might infer that it affects sys.getdefaultencoding(), which it shouldn't.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, May 20 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
- Previous message: [Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING
- Next message: [Python-Dev] Proposal: new environment variable PYTHONSTDOUTENCODING
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]