Spoiler alert!!!
Applied #2.2. (from below) to the original .whls, and published them on [GitHub]: CristiFati/Prebuilt-Binaries - (master) Prebuilt-Binaries/PyWin32/v225 (win_amd64, win32 for Python 3.8).
After installing (one of) them, existing code should work OOTB (with respect to this issue).
Install steps:
Download the .whl that matches your Python architecture (064bit, 032bit - for more details on getting Python architecture, check [SO]: How do I determine if my python shell is executing in 32bit or 64bit? (@CristiFati's answer) (the question is about OSX, but other platforms are covered as well)), it will most likely be 64bit (win_amd64), from the above URL.
For example, I downloaded it in L:\Downloads
Invoke the PIP installer on it ([SO]: How to install a package for a specific Python version on Windows 10? (@CristiFati's answer)). Something like:
(${path_to_your})python.exe -m pip ${path_to_the_downloaded_pywin32_whl}
Example:
"e:\Work\Dev\VEnvs\py_pc064_03.08.00_test0\Scripts\python.exe" -m pip "L:\Downloads\pywin32-225-cp38-cp38-win_amd64.whl"
The problem has been reported on [GitHub]: mhammond/pywin32 - python 3.8.
The above URL references 2 more:
In the same time, I did some digging of my own and discovered that (for win32api.pyd) it's pywintypes38.dll (which is a dependency for the .pyds) that is not found (I also specified this in a comment on the issue).
Solutions (actually workarounds (more or less) until an official and backwards compatible fix is released):
Force pywintypes38.dll load by importing it (as it's also a Python module and in this scenario it doesn't fall under the above rule) before any PyWin32 module:
import pywintypes
import win32api
If working with COM, you'd need import pythoncom
Adding pywin32_system32 to the .dll search paths (following the new model from above). There are multiple ways:
v-python's comment from the issue URL which provides a small snippet (I didn't test it)
I also submitted [GitHub]: mhammond/pywin32 - Support for Python 3.8, where I do everything in the pywin32.pth file ("executed" when the interpreter starts, so no changes needed for existing code). Unfortunately, there is a problem with the AppVeyor automated tests which fail (but for some other reasons), so it has been stuck there for a while. Note that in the meantime, the PR was closed and another (similar) approach was pushed. Note that v226 (released on 20191110) which contains the fix, does not work on VirtualEnv ([SO]: PyWin32 (226) and virtual environments (@CristiFati's answer)).
Anyway, applying the changes locally (1) (on both my Python VirtualEnvs), solved the problem (on one, and didn't break the other):
[cfati@CFATI-5510-0:e:\Work\Dev\StackOverflow\q058631512]> sopr.bat
### Set shorter prompt to better fit when pasted in StackOverflow (or other) pages ###
[prompt]> "e:\Work\Dev\VEnvs\py_064_03.07.03_test0\Scripts\python.exe" -c "import win32api"
[prompt]> "e:\Work\Dev\VEnvs\py_064_03.08.00_test0\Scripts\python.exe" -c "import win32api"
[prompt]>
Other ways like copying the .dlls (e.g. in %SystemRoot%\System32), or SymLinking them, but (personally) I wouldn't recommend those
Check:
Update #0
[PyPI]: pywin32 227 (which addresses this issue), was published on 20191114!
Footnotes