"env" parameter to "popen" won't accept Unicode on Windows - minor Unicode bug

Diez B. Roggisch deets at nospam.web.de
Tue Jan 15 04:47:53 EST 2008


John Nagle wrote:

> Benjamin wrote:
>> On Jan 14, 6:26 pm, Bjoern Schliessmann <usenet-
>> mail-0306.20.chr0n... at spamgourmet.com> wrote:
>>> John Nagle wrote:
>>>> It turns out that the strings in the "env" parameter have to be
>>>> ASCII, not Unicode, even though Windows fully supports Unicode in
>>>> CreateProcess.

That's of course nonsense, they don't need to be ascii, they need to be
byte-strings in whatever encoding you like.

>>> Are you sure it supports Unicode, not UTF8 or UTF16? Probably using
>>> something like u"thestring".encode("utf16") will help.
>> Otherwise: bugs.python.org

John's understanding of the differences between unicode and it's encodings
is a bit blurry, to say the least.

>      Whatever translation is necessary should be done in "popen", which
> has cases for Windows and POSIX.  "popen" is supposed to be cross-platform
> to the extent possible.  I think it's just something that didn't get fixed
> when Unicode support went in.

Sure thing, python will just magically convert unicode to the encoding the
program YOU invoke will expect. Right after we introduced the

solve_my_problem()

built-in-function. Any other wishes?

If I write this simple program

------ test.py -------
import os
import sys

ENCODDINGS = ['utf-8', 'latin1']

os.env["MY_VARIABLE"].encode(ENCODINGS[int(sys.argv[1])])
------ test.py -------


how's python supposed to know that

suprocess.call("python test.py 0", env=dict(MY_VARIABLE=u'foo'))

needs to be UTF-8?

Diez



More information about the Python-list mailing list