[Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

[Michael Foord]

Amaury Forgeot d'Arc wrote:
> Hi,
>
> 2009/7/23 Christian Heimes <lists at cheimes.de>:
>   
>> Lisandro Dalcin wrote:
>>     
>>> Eric seems to be working on a GSoC for PFS related to improving
>>> subprocess. Even in such case this list is not the right place to make
>>> these posts??
>>>       
>> Eric didn't say that he is working on a GSoC project for the PSF. Anyway
>> the Python general mailing list might still be a better place. IMHO he
>> can reach many more competent Python developers there who can help him
>> with this particular problem.
>>     
>
> Furthermore it was more a Windows question than a Python one.
> Anyway we continued the discussion privately and I try to be helpful.
>
>   
>> By the way I don't think that ctypes is the right way to go here. ctypes
>> is very handy if you need a quick solution. However I wouldn't use it as
>> a permanent solution for the subprocess module. It's tricky to get
>> ctypes based solutions right on multiple platforms (32 vs 64bit). It's
>> harder to debug a ctypes solutions rather than a C extension, too. I
>> assume that calling overhead is greater than a pure C extension.
>>     
>
> And some distributions may choose to not distribute the ctypes module.
> No stdlib module should require it.
>   

A big advantage of using ctypes is that it works cross-implementation - 
on IronPython and PyPy already and on Jython soon. I'd like to see more 
standard library modules use it. Distributions that choose not to 
include it are crippling their Python distribution.

Michael Foord

> OTOH ctypes is the perfect tool for rapid development with the win32
> api, specially when the compiler is far away.
>
>   
>> Can ctypes release the GIL for a function call?
>>     
>
> Yes, see http://docs.python.org/library/ctypes.html#ctypes.CFUNCTYPE
>
>   


-- 
http://www.ironpythoninaction.com/