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

[Diez B. Roggisch]

Brian Smith wrote:

> Diez B. Roggisch wrote:
>> 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?
> 
> There's no reason to be rude.

If you'd know John, you'd know there is.
 
> Anyway, at least on Windows it makes perfect sense for people to expect
> Unicode to be handled automatically. popen() knows that it is running on
> Windows, and it knows what encoding Windows needs for its environment
> (it's either UCS2 or UTF-16 for most Windows APIs). At least when it
> receives a unicode string, it has enough information to apply the
> conversion automatically, and doing so saves the caller from having to
> figure out what exact encoding is to be used.


For once, the distinction between windows and other platforms is debatable.
I admit that subprocess contains already quite a few platform specific
aspects, but it's purpose is to abstract these away as much as possible.

However, I'm not sure that just because there are wide-char windows apis
available automatically means that using UCS2/UTF-16 would succeed. A look
into the python sources (PC/_subprocess.c) reveals that someone already
thought about this, but it seems that just setting a
CREATE_UNICODE_ENVIRONMENT in the CreateProcess-function should have been
easy enough to do it if there weren't any troubles to expect.

Additionally, passing unicode to env would also imply that os.environ should
yield unicode as well. Not sure how much code _that_ breaks.

Diez