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

[Adrian Buehlmann]

On 2011-02-08 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.
> 

I don't understand this.

I suspect my understanding of "pure Python" is too fuzzy.

What I have understood so far is:

- For the current codebase of Mercurial, nlinks() is broken if
  pywin32 is not installed
- pure/osutil.py defines posixfile = open, which is horrible for
  Windows due to the problems described on the UnlinkingFilesOnWindows
  wiki page

What I suspect:

- pywin32 is only available for CPython

So what entails "current non-ctypes pure Python Windows support" actually?

I suspect it's completely fictional.