[Python-Dev] Re: Re: subprocess - updated popen5 module

[Neil Hodgson]

Guido van Rossum:

> I don't know. Writing Windows interface modules is a highly
> specialized form of torture, requiring arcane expertise. Most Python
> users don't have that expertise, and could do more damage than good.
> I'd expect those folks that *do* have the expertise to have learned
> what they know by coding in C/C++, so I don't see that requiring the
> use of C is any particular burden.

   Visual Basic programmers often write to the Win32 API without knowing
enough C to write an extension module. They can declare a function and then
call it:

Declare Function GetComputerName Lib "kernel32" Alias "GetComputerNameA"
 (ByVal sBuffer As String, lSize As Long) As Long
strString = String(255, Chr$(0))
GetComputerName strString, 255

   The incantations are a little more arcane than for C but there is quite a
lot of documentation available about how to do this so VB programmers often
don't need to read the C header files. One source is win32api.txt which
lists the structs, constants, and functions in the Win32 API as VB
declarations.

> And what about all the stuff that's defined in header files?

   ctypes doesn't yet have a good solution to header files.
http://starship.python.net/crew/theller/moin.cgi/WrappingWin32Api

> In the
> past, in the Unix world, I experimented with translating .h files to
> Python modules to save me from the burden of having to  add large
> numbers of symbol definitions to C extensions. (Look for files named
> Lib/plat-XXX/regen in the source tree.) One by one, that approach has
> proven to be problematic, and nearly all of those have eventually been
> turned into systematic lists of symbol definitions in C code.
> See for example the posix, socket, fcntl, and signal modules.

   Where the problems are caused by multiple vendor or version variations
then Windows is much more stable with additions occurring often but
amendments, removals and world changes (Win16->Win32) being very rare.
Looking at the all_ins function in posix, it seems to have been made by
hand. This wouldn't be a great approach to a large API (there are thousands
of values #defined in Win32) where finding the names of the constants (and
not, for example, function names which are often #defined to either narrow
or wide functions) is as difficult as finding their values.

   When coding an interface module in Python, it would be fastest to copy
just the relevant declarations from the headers or win32api.txt and convert
to Python syntax by hand.

   Neil