Closed Avasam closed 2 months ago
If both the old .pyd
and .py
are found in the same repository, it is indeed likely importing the .pyd
will take precedence.
Is that an issue? Most symbols were the exact same, built from win32gui. I guess we'd want to avoid a fresh install / full re-install from possibly causing some behavior change.
I'm not totally certain how to best handle that. I could "compile" the .py
file with Cython or mypyc. to ensure it overrides the old winxpgui.pyd
. Should still be faster and simpler.
Edit: or learn to do the exact same re-exports I'm doing, but in C (could maybe shortcut it using cythonize) and build the very simple module.
Is that an issue?
Hrm, maybe not. I guess a risk is that later pywintypes.dll ends up changing symbols, meaning an old winxpgui fails to load. OTOH though, that seems an edge case so maybe it's fine.
Ok, let's YOLO this given the benefit of killing this code is real and that risk I mentioned above is both theoretical and temporary
If you're good with it, I'm good with it. It removes so much complexity and speeds up build times.
As mentioned in https://mail.python.org/pipermail/python-win32/2024-March/014879.html
I went the very simple (and fast to "compile" 😉 ) route of having a pure python module that re-exports what we need.
To remove pywin32's own usage of
winxpgui
in code, I had to touch theietoolbar
demo, which I had to fix to test.I could remove it now, or leave it for a follow-up PR to keep this well-contained