[Python-ideas] win32 extensions

Matt Joiner anacrolix at gmail.com
Wed Sep 14 06:13:58 CEST 2011


Well...

ReadDirectoryChangesW is present in pyfilesystem, that Nick mentioned
in another thread. In fairness you shouldn't expose this without
exposing inotify for Linux, and whatever nasty equivalents are
available on other systems.

pywin32 gives you full access to the Windows kernel interface. The
same functionality is not bundled in the standard library for Linux.
To use Massimo's example regarding file locking, just this morning I
had to write a ctypes wrapper around struct flock for this purpose
because the fcntl module is only a partial implementation. If the full
Windows API is made available, you might as well complete some of
those half-done modules now that the single biggest sore thumb
(Windows) for OS interfaces will be laid bare.

Python is well respected for its cross platform support. Making
bindings available in both cross platform and native forms will
greatly improve uptake of Python. My thoughts are that more effort
should be made to completely expose Unix/Linux/Mac interfaces before
(or simultaneously) with making the entire Windows API available.

On Wed, Sep 14, 2011 at 1:00 PM, Brian Curtin <brian.curtin at gmail.com> wrote:
> On Tue, Sep 13, 2011 at 21:28, Matt Joiner <anacrolix at gmail.com> wrote:
>> Do we really need to be encouraging use of Windows APIs in Python?
>
> I don't think we're encouraging anything, nor do I think we need to.
> People have already been doing so for quite some time - it's a fact of
> life.
>
> If I want to write a tool which uses Windows' ReadDirectoryChangesW
> API, how do I do that today? I either write a C extension (which I've
> done), or I use pywin32. I must be missing something, because your
> question comes off as saying "don't solve that problem".
>
>> Given the greater user base of Windows, is there a danger this could
>> encourage the littering of Windows-only "workarounds" in many
>> projects?
>
> I don't think the inclusion of this package is going to enlighten
> people on the ability to make platform specific workarounds in their
> code. They've already been doing this with pywin32 or extension
> modules where necessary, and I don't think that's a such bad thing.
> Obviously it's great when Python provides a way to solve a
> cross-platform problem with one solution, e.g., listing directory
> contents, but it's not all sunshine and rainbows. Sometimes working
> with those contents requires a platform specific operation.
>



More information about the Python-ideas mailing list