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

[John Nagle]

Diez B. Roggisch wrote:
> 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.

     The problem is that only the NT-derived Microsoft systems talk Unicode.
The DOS/Win16/Win9x family did not. But they did have CreateProcess.
So the current code will handle Win9x, but not Unicode.

     When do we drop support for Win9x?  It probably has to happen in
Python 3K, since that's Unicode-everywhere.

					John Nagle