[PATCH 1 of 5] port win32.py to using the Python ctypes library

[Dan Villiom Podlaski Christiansen]

On 8 Feb 2011, at 21:36, Matt Mackall wrote:

> On Tue, 2011-02-08 at 20:58 +0100, Adrian Buehlmann wrote:
>> On 2011-02-08 20:42, Matt Mackall wrote:
>>> On Tue, 2011-02-08 at 12:31 -0600, Steve Borho wrote:
>>>> On Tue, Feb 8, 2011 at 12:14 PM, Adrian Buehlmann <adrian at cadifra.com 
>>>> > wrote:
>>>>> On 2011-02-08 18:48, Steve Borho wrote:
>>>>>> On Tue, Feb 8, 2011 at 10:52 AM, Adrian Buehlmann <adrian at cadifra.com 
>>>>>> > wrote:
>>>>>>> # HG changeset patch
>>>>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>>>>> # Date 1297121623 -3600
>>>>>>> # Node ID 3ba4920422e9abcdc8b8634c5c12c68051286a8c
>>>>>>> # Parent  69e69b131458023d21ec40aa48fc5299e43ce69b
>>>>>>> port win32.py to using the Python ctypes library
>>>>>>>
>>>>>>> The pywin32 package is no longer needed.
>>>>>>>
>>>>>>> ctypes is now required for running Mercurial on Windows.
>>>>>>>
>>>>>>> ctypes is included in Python since version 2.5. For Python  
>>>>>>> 2.4, ctypes is
>>>>>>> available as an extra installer package for Windows.
>>>>>>>
>>>>>>> Also moved spawndetached() from windows.py to win32.py and  
>>>>>>> fixed it, using
>>>>>>> ctypes as well. spawndetached was defunct with Python 2.6.6  
>>>>>>> because Python
>>>>>>> removed their undocumented subprocess.CreateProcess. This fixes
>>>>>>> 'hg serve -d' on Windows.
>>>>>>>
>>>>>
>>>>> [big snip]
>>>>>
>>>>>>>
>>>>>>> -try:
>>>>>>> -    # override functions with win32 versions if possible
>>>>>>> -    from win32 import *
>>>>>>> -except ImportError:
>>>>>>> -    pass
>>>>>>> +from win32 import *
>>>>>>
>>>>>> This probably deserves a separate patch, but there's little  
>>>>>> point in
>>>>>> keeping both a windows.py and win32.py now.
>>>>>>
>>>>>
>>>>> That's quite wrong, since windows.py depends on osutils.c and  
>>>>> win32.py
>>>>> doesn't (by the end of this series).
>>>>>
>>>>> I'd like to keep win32.py free of depending on osutils.c, so we  
>>>>> can use
>>>>> win32.py (as modified by this series) for pure mercurial in the  
>>>>> future.
>>>
>>> Do non-Cpython versions of Python support ctypes? If not, then  
>>> this is
>>> not very useful.
>>>
>>
>> The combination of Windows+Mercurial+Python is obscure enough for  
>> me to
>> not have ever tried anything else than CPython.
>>
>> So: I don't know.
>>
>> But if this separation of Windows low level utilities into a part  
>> that
>> *is* importing the ctypes library (but does not depend on C code like
>> osutils.c) and a part that doesn't, is itching people, then it's no
>> problem at all to pour everything into a big single python source  
>> file.
>
> My point is only that unless non-CPython versions of Python support
> ctypes, we can't ditch the current non-ctypes pure Python Windows
> support.

PyPy has support for ctypes. I believe they are working on integrating  
them with the JIT compiler, so they would be faster than their Python  
C API support.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com