[Python-ideas] win32 extensions
Massimo Di Pierro
massimo.dipierro at gmail.com
Wed Sep 14 06:28:33 CEST 2011
On Sep 13, 2011, at 11:13 PM, Matt Joiner wrote:
> 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
>> 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
>> 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.
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas