Author giovannibajo
Recipients giovannibajo
Date 2008-02-16.16:27:44
SpamBayes Score 0.0268176
Marked as misclassified No
Message-id <>
Under Windows, sys.argv is created through the Windows ANSI API.

When you have a file/directory which can't be represented in the 
system encoding (eg: a japanese-named file or directory on a Western 
Windows), Windows will encode the filename to the system encoding using
what we call the "replace" policy, and thus sys.argv[] will contain an
entry like "c:\\foo\\??????????????.dat".

My suggestion is that:

* At the Python level, we still expose a single sys.argv[], which will 
contain unicode strings. I think this exactly matches what Py3k does now. 

* At the C level, I believe it involves using GetCommandLineW() and 
CommandLineToArgvW() in WinMain.c, but should Py_Main/PySys_SetArgv() be 
changed to also accept wchar_t** arguments? Or is it better to allow for 
NULL to be passed (under Windows at least), so that the Windows
code-path in there can use GetCommandLineW()/CommandLineToArgvW() to get
the current process' arguments?
Date User Action Args
2008-02-16 16:27:46giovannibajosetspambayes_score: 0.0268176 -> 0.0268176
recipients: + giovannibajo
2008-02-16 16:27:46giovannibajosetspambayes_score: 0.0268176 -> 0.0268176
messageid: <>
2008-02-16 16:27:45giovannibajolinkissue2128 messages
2008-02-16 16:27:44giovannibajocreate