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

Matt Mackall mpm at selenic.com
Tue Feb 8 14:36:32 CST 2011


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list