[Python-3000] Unicode and OS strings

[Nicholas Bastin]

On 9/28/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Nicholas Bastin schrieb:
> > On 9/22/07, martin at v.loewis.de <martin at v.loewis.de> wrote:
> >> argc/argv does not exist on Windows (that you seem to see it
> >> anyway is an illusion), and if it did exist, it would be characters,
> >> not bytes.
> >
> > Of course it exists on Windows.  argc/argv are defined by the C
> > standard, and say what you will about Windows, but it has a conforming
> > implementation.
>
> It doesn't. Microsoft has a conforming implementation of C for Windows
> (Visual C), but Windows does not.

msvcrt ships with the operating system - I'd call that a conforming
implementation.  Programs running in the standard C runtime are just
as much applications as programs using the Win32 API in advapi32.  But
we have drifted far from the topic at hand, since this is obviously a
misunderstanding on whether Windows was used to refer to the OS or the
API.

I still regard handling argv as anything other the raw bytes that come
from the host as bad.  argv *means* something - regardless of whether
WinMain provides it or not.  If we're going to call something
sys.argv, then presumably that was done because there was a
conventionally accepted meaning to it, and I would argue that meaning
comes from standard C.  If it were called sys.lpCmdLine, then I'd say
you have a point, but it isn't, and to the degree that it isn't, I
believe that we should emulate the standard argv behaviour (especially
since lpCmdLine doesn't include the program name).

Of course, on Win32 this entire issue is moot, given the availability
of CommandLineToArgvW(), which would allow you to provide a nice
convenient unicode argv.  However, since not all supported platforms
provide us this functionality, I would suggest we store the result of
any effort to transform argv into unicode into some other well named
member of sys (or make it a function call so it can be computed on
demand if you don't want it in the first place).  Changing the current
meaning of argv will break applications which already handle this
problem, and while I realize that that's not a showstopper for Python
3k, I don't see any particular benefit to introducing this
inconsistency, rather than adding something more defined, like
sys.arguments.

--
Nick