os.system and unicode arguments fail on Win32

[Tim Daneliuk]

Martin v. Löwis wrote:
> Tim Daneliuk <tundra at tundraware.com> writes:
> 
> 
>>>This will change in Python 2.3. In many cases, Python 2.2 will also
>>>accept Unicode strings in file system API on Windows. For Python 2.3,
>>>and NT+, all Unicode strings are usable as file names.
>>>This still does not include os.system, or environment variables.
>>
>>What is the restiction here that prevents 2.3 from doing things
>>the same way with these portions of the OS.
> 
> 
> I have problems parsing this sentence. Is this a question?


Sorry - my lousy English is almost as bad as my terrible German ;))

> 
>>Incidentally, it seem strange to me that Win32 is inherently
>>a unicode environment but os.system (which presumably mapps
>>to some Win32 API) has trouble with unicode strings...-
> 
> 
> If you are asking why Python 2.3 won't support Unicode strings to
> os.system? Primarily, because nobody has contributed code to do so. Do
> you volunteer?

Ummm, no - I much prefer writing for Unix or realtime systems.  Working
at this low a level in Win32 gives me nightmares ...

><SNIP>

> Notice that, on Windows, there are *two* native encodings: the ANSI
> code page (what the ANSI Win32 API expects, and which is used in the
> windowing system), and the OEM code page (which the FAT file system
> uses on disk, and the command.com/cmd.exe terminal windows, unless
> setcp.exe is invoked)

(Clearly) I am not too familiar with this, so I ran the commands
as you suggest and got ('en_US', 'cp1252') just as you've explained.
So... where does 'mcbs' come from?  That is, why is the translation
from unicode to bytestring not:

                y = encode(unicode-var, "cp1252")

or conversely

                u = unicode(byte-var, "cp1252")

Just wondering ...

-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com