STINNER Victor <victor.stin...@haypocalc.com> added the comment:

> We run into problems because we have two inconsistent
> encodings, ...

What? No. We have problems because we don't use the same encoding to decode and 
to encode the same data type. It's not a problem to use a different encoding 
for each data type (stdout, filenames, environment variables, ...).

--

About the 3rd encoding: it will be just the locale encoding. Use the locale 
encoding to encode/decode command line arguments and environment variables is 
complelty compatible with Python 3.1, because Python 3.1 initializes the 
filesystem encoding with the locale encoding. Use the locale encoding helps the 
interoperability because other programs use the same encoding.

Mac OS X is a special case. Filesystem encoding is utf-8 on this OS, whereas 
the locale encoding depends on LANG variable. If I understood MvL proposition 
correctly, we should not rely on the locale on Mac OS X. So the "3rd encoding" 
and the filesystem encodings should be hardcoded to utf-8?

--

The "third encoding" is no more controlable by a special environment variable, 
only by classic locale environment variables (LC_ALL, LC_CTYPE, LANG). Is it a 
problem? I remember a comment from MAL saying that it may be a problem for CGI 
for the environment variables because some (all?) variables are not encoded 
with the locale encoding (but the HTML encoding?). I don't know if Python 
should workaround CGI specific issues. In Python 3.2, we have now os.environb: 
it's now possible to use a different encoding for each variable.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to