[Python-Dev] adding Py{String|Unicode}_{Lower|Upper} and fixing CreateProcess in _subprocess.pyd and PyWin32

[M.-A. Lemburg]

Trent Mick wrote:
> 
> There is a subtlety in CreateProcess in the Win32 API in that if one 
> specifies an environment (via the lpEnvironment argument), the 
> environment strings (A) must be sorted alphabetically and (B) that sort 
> must be case-insensitive. See the Remarks section on:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp 
> 
> 
> If this is not done, then surprises can happen with the use of 
> {Get|Set}EnvironmentVariable in the created process:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getenvironmentvariable.asp 
> 
> 
> Neither _subprocess.pyd (supporting the new subprocess.py module on 
> Windows) nor PyWin32's CreateProcess binding do this. I haven't done so 
> yet, but I should be able to put together a test case for subprocess.py 
> for this. We came across such a surprise when using my process.py module 
> that uses this PyWin32 code (which it looks like _subprocess.c borrowed).
> 
> Fixing (A) is easy with a "PyList_Sort(keys)" and some other minor 
> changes to _subprocess.c::getenvironment() -- and to 
> win32process.i::CreateEnvironmentString() in PyWin32.
> 
> However, I'd like some guidance on the best way to case-insensitively 
> sort a Python list in C code to fix (B). The best thing I see would be 
> to expose PyString_Lower/PyUnicode_Lower and/or 
> PyString_Upper/PyUnicode_Upper so they can be used to .lower()/.upper() 
> the given environment mapping keys for sorting.
> 
> Does that sound reasonable? Is there some problem to this approach that 
> anyone can see?

If you want to sort the list in C, it's better to provide
a C sorting function. That function can then use
Py_UNICODE_TOUPPER(ch) and toupper() for the comparison.
Calling the .upper() method on the object would be much
too expensive. Dito for creating new objects just for the
purpose of comparing two objects.

I think it would be worthwhile to consider replacing the
string implementation's direct usage of toupper(), tolower()
etc. with a Py_STRING_TOUPPER(ch) et al. approach much
like the Unicode object does - at least for consistency
reasons.

In the future, I think it would be best to move
away from the C lib implementation of toupper(), tolower()
et al. because these are affected by the current locale
settings which is not what you'd normally expect in
Python.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 27 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::