it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

diff --git a/lang/python/helpers.h b/lang/python/helpers.h
index 61f538e2..2b772cef 100644
--- a/lang/python/helpers.h
+++ b/lang/python/helpers.h
@@ -27,7 +27,8 @@
 
 #ifdef _WIN32
 #include <windows.h>
-#define write(fd, str, sz) {DWORD written; WriteFile((HANDLE) fd, str, sz, &written, 0);}
+#define write(fd, str, sz) win32_write(fd, str, sz)
+inline int win32_write(int fd, const void* str, size_t sz) { DWORD written; if (! WriteFile((HANDLE) fd, str, sz, &written, 0)) return -1; return written; }
 #endif
 
 /* Flag specifying whether this is an in-tree build.  */

The APIs are mostly compatible. However, it would need the right file descriptor. It could either be a crt file descriptor, or a HANDLE-in-disguise (however note, a HANDLE is a pointer (64bit), but in windows an int is 32bits, so on 64 bits Windows such casting is not necessarily safe).

I wonder if python is actually passing a HANDLE in the fd parameter, as otherwise this macro makes little sense. It is also quite dated code.
However, I wonder

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.