Python language projections

[LeonarddeR]

Hereby I'd like to suggest the creation of Python language projections for the Win32 API. I'm one of the developers of the NVDA screen reader that is written in Python for the most part and heavily relies on talking to the Win32 API. Currently this is performed using ctypes.

[kennykerr]

See #174 (comment)

[mikebattista]

#183 captures the guidance for new language projection requests.

[mikebattista]

@zooba and I met to brainstorm what an ideal Python projection would look like based on learnings from projects like pywin32 and ctypes. Below are the notes from that discussion for review and comment.

• Provide maximum API coverage for Win32 and COM
• APIs should be exposed as friendly Python interfaces rather than like ctypes
• Achieve seamless acquisition and “pay for play” by providing granular PIP packages under the windows root
  • These packages would probably align with the namespaces we’ve added in the Win32 metadata
  • Ideally, the tooling used to build these packages could be used by developers directly to produce their own packages for just the APIs they need, if the Win32 namespaces aren’t granular enough
• These packages sim-ship with Python updates so they are available at launch

Let us know your thoughts and comments.

[LeonarddeR]

That said, the specific work proposed here is for a Python projection for ... COM.

Does that mean you're intending to provide a full blown alternative to comtypes? Or only for the WIN32 stuff that'relies on it?

[mikebattista]

We are looking at existing projects in the space as part of this. Obviously we're not going to build something if everyone's happy with existing support, though what we typically hear across languages is that manually-maintained projects that provide friendly interfaces over Win32 and COM APIs have spotty coverage and can be slow moving with high maintenance overhead for the community. A metadata-based projection would help with that.

[lunixbochs]

manually-maintained projects that provide friendly interfaces over Win32 and COM APIs have spotty coverage and can be slow moving with high maintenance overhead for the community

This is basically how I'd describe the current Windows API libraries for Python. I would strongly prefer a proper win32/com projection for Python instead.

My vote would be to avoid CFFI/ctypes, and go straight for an extension module with precompiled packages for any non-EOL cpython versions. Long term can migrate the extension to whatever becomes of HPy to provide better support for GC'd Python interpreters like pypy.

(I ended up in this thread after looking at the comtypes client for an API and hoping there was a projection I could use instead. Alas.)

[LeonarddeR]

I like this idea.

It is probably best to do something based on C++ Win32. Aren't the WinRT bindings for Python based on C++/WinRT as well?

[lunixbochs]

Something else to watch out for here is: I think bundling a whole namespace together into one Python package means you're forced to the max Windows version and runtime libraries needed for the whole namespace. In windows-rs, I noticed that binding * from a namespace would incur additional runtime library dependencies.

One way to work around that could be to split a namespace into multiple numbered packages that indicate the minimum Windows version?

[byehack]

I just should mention https://github.com/ynkdir/py-win32more, the win32metadata based python package.
it's not stable after few months (api may changed in future releases) but still provides good usability.

[mikebattista]

Awesome! I've added it to the list of projections in the README.

[LeonarddeR]

The readme of this project mentions both unmaintained and untested, so I'm afraid that's a no go for the distant future.

[LeonarddeR]

I've been pondering for several days about something @kennykerr can probably assess for feasibility.
There is the PyO3 Rust crate that allows creating Python bindings from Rust. A custom project could create wrappers around the windows or windows-sys crate, but it is probably more effectieve to adapt the binding generator to create PyO3 compatible structs, enums and functions to begin with.