Free-threaded support?
Has anyone here given thought on testing this module with the no-GIL version of the Python interpreter yet?
I'm not aware of anyone looking at this. It's worth noting that there are quite a few places where the GIL is used to prevent concurrent access, so identifying these seems like the first step.
As far as CI builds go, https://github.com/actions/setup-python/issues/771 would be nice. ~~But if it's somehow not available by the time pywin32 has nogil support, deadsnakes already offer a nogil python action: https://github.com/deadsnakes/action~~
As far as CI builds go, actions/setup-python#771 would be nice. But if it's somehow not available by the time pywin32 has nogil support, deadsnakes already offer a nogil python action: https://github.com/deadsnakes/action
deadsnakes is only tested on Ubuntu
As far as CI builds go, actions/setup-python#771 would be nice.
It's also possible uv gets to it first: https://github.com/astral-sh/uv/issues/7193
Here's a workflow manually installing Python 3.13t: https://github.com/mhammond/pywin32/pull/2395 It builds, but as expected, tests don't get very far:
--- Running 'D:\a\pywin32\pywin32\win32/test/testall.py' --- *** Test script 'D:\a\pywin32\pywin32\win32/test/testall.py' exited with 3221225477 --- Running 'D:\a\pywin32\pywin32\Pythonwin/pywin/test/all.py' --- Fatal Python error: PyWinInterpreterState_Ensure: pywintypes: can not setup interpreter state, as current state is invalid Python runtime state: unknown
*** Test script 'D:\a\pywin32\pywin32\Pythonwin/pywin/test/all.py' exited with 3221226505 --- Running 'D:\a\pywin32\pywin32\com\win32com\test\testall.py' --- *** Test script 'D:\a\pywin32\pywin32\com\win32com\test\testall.py' exited with 3221225477 The following scripts failed > D:\a\pywin32\pywin32\win32/test/testall.py > D:\a\pywin32\pywin32\Pythonwin/pywin/test/all.py > D:\a\pywin32\pywin32\com\win32com\test\testall.py
Edit: It's even worst in 3.14t as it doesn't build at all: #2674
win32/src/win32file_swig.cpp(1318): error C2039: 'ob_refcnt': is not a member of 'PyOVERLAPPED'
This is unfortunately not something I'll be able to provide much help with. Contributions are more than welcome !
Hi @mhammond Do we have any plan to release free threaded version of pywin32 ?
Hi @mhammond Do we have any plan to release free threaded version of pywin32 ?
No, I've no plans to work on this and I've heard no one else say they will, and even if they do, I suspect the patches will be too large and risky to accept.
=(
Hi @mhammond Do we have any plan to release free threaded version of pywin32 ?
No, I've no plans to work on this and I've heard no one else say they will, and even if they do, I suspect the patches will be too large and risky to accept.
@mhammond
There is a need now to move forward with supporting the free-threaded version, as some of the most popular libraries are working on it, so we may say the community will soon be moving toward the free-threaded version of Python—mostly for doing AI-related stuff, but also to be better aligned with today’s computing technology and capabilities.
https://py-free-threading.github.io/tracking/
@mhawash You are more than welcome to provide patches as Pull Requests to work towards Free-Threaded support for pywin32. Or find someone who would. There is a lot of unknowns on the way there, and we expect it to be an arduous road. I don't know if partial support would be accepted either (see similar discussions for PyPy https://github.com/mhammond/pywin32/issues/1289). I'm somewhat open to it, as I have projects that use pywin32 w/o using COM objects for example.
Thank you for sharing that site, I like seeing more resources like https://py-free-threading.github.io/#advanced-topics-for-package-maintainers
https://github.com/mhammond/pywin32/issues/2303#issuecomment-2186790621
It's worth noting that there are quite a few places where the GIL is used to prevent concurrent access, so identifying these seems like the first step.
https://github.com/mhammond/pywin32/issues/2303#issuecomment-2607368209
No, I've no plans to work on this and I've heard no one else say they will, and even if they do, I suspect the patches will be too large and risky to accept.
https://github.com/jupyterlab/jupyterlab/issues/17887#issuecomment-3341995611
Also, for what it’s worth I don’t think the pywin32 maintainer said they won’t support free-threaded python, just that no one has worked on it yet and they suspect it will be a big task.
Correct. It's not that we don't want to support FreeThreaded Python (I myself have an app that relies on pywin32 that I would love to see use FreeThreaded Python eventually). It's moreso that none of the current (3) pywin32 maintainers have the will, free-threaded expertise, and/or free time to look into and learn everything necessary to make it work. Especially given that pywin32 actively relies on the GIL in a handful of places, so we're expecting a lot of pain and risks in a potential migration.
So if it happens, it's likely to be from external contributors.