Windows XP - Environment variable - Unicode

John Roth newsgroups at jhrothjr.com
Sun Jul 13 17:11:18 CEST 2003


"Martin v. Löwis" <martin at v.loewis.de> wrote in message
news:m33chakd25.fsf at mira.informatik.hu-berlin.de...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>
> > The OP's question revolved around ***which*** code page was
> > being used internally. Windows uses Unicode. That's not the same
> > question as what code set Python uses to attempt to translate Unicode
> > into a single byte character set.
>
> Yes and no. What Windows uses is largely irrelevant, as Python does
> not use Windows here. Instead, it uses the Microsoft C library, in
> which environment variables are *not* stored in some Unicode encoding,
> when accessed through the _environ pointer.

I've found at various times that using the C library causes lots of
problems with Microsoft.

> > As to more difficult, as I said above, I haven't perused the source,
> > so I can't comment on that. If I had to do it myself, I'd probably
> > start out by always using the Unicode variant of the Windows API
> > call, and then check the type of the arguement to environ() to determine
> > which to pass back. I'm not sure whether or not I'd throw an exception
> > if the actual value couldn't be translated to the current SBCS code.
>
> Notice that os.environ is not a function, but a dictionary. So there
> is no system call involved when retrieving an environment
> variable. Instead, they are all precomputed.

Good point. That does make it somewhat harder; the routine
would have to precompute both versions, and store them with
both standard strings and unicode strings as keys. Whether the
overhead would be worth it is debatable. It's not, however,
all that difficult to understand for the user of the facility, though.
It would work exactly the same way the file functions work: if
you use a unicode key, you get a unicode result.

John Roth

>
> Regards,
> Martin
>






More information about the Python-list mailing list