Requiring windows interface modules to be written in C rather than Python reduces the number of Python users that can add, modify and fix these modules. It also increases the amount of effort involved in working on these modules.
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. Rather, having to be familiar with the intricate details of the mapping between C and Python is likely to trip up folks occasionally. And what about all the stuff that's defined in header files? 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)