//And there's no handle at all?
There is one (check thread_nt.h) you have to "propagate" HANDLE to Pythom level. That's why, you have to change the interpreter. Do not forget, that thread is a build-in module.
Sounds fine with me. A fileno (or whatever) function can be added to threading.Event on all platforms, giving access to internal file descriptor/handle.
//I wouldn't want to derive from Event since my goal would be to submit a patch to make subprocess.Popen.wait take an optional threading.Event to kill the process.
And that's it? Right now aquire_lock is non-interruptable, as a result your Popen.wait is also non-interruptable, but if you pass derived event you will be able to handle more generic cases.
I'm not 100% sure I understand what you say. Support killing the process with any handle, not only an event, would be a good thing. But it doesn't change the fact that, IMHO, the usefulness of threading.Event is just too limited if it doesn't support select or WaitForMultipleObjects. I think also that threading.Thread should give access to its internal handle (at least thread module does).
Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list
