... David, Anthony and I all have this problem today. Tim Peters can see the problem and can see it exists (even if he believes my current implementation is incorrect).
I haven't looked at this in at least 2 years. Back when I did, I thought there *may* be rare races in how the Win32 classes initialized themselves. That may not have been the case in reality. I'd like to intensify the problem, though: you're in a thread and you want to call a Python API function safely. Period. You don't know anything else. You don't even know whether Python has been initialized yet, let alone whether there's already a thread state, and/or an interpreter state, sitting around available for you to use. You don't even know whether you're a thread created by Python or via some other means. I believe that, in order to end this pain forever <heh>, even this case must be made tractable. It doesn't preclude that a thread knowing more than nothing may be able to do something cheaper and simpler than a thread that knows nothing at all. I'd also like to postulate that proposed solutions can rely on a new Python C API supplying a portable spelling of thread-local storage. We can implement that easily on pthreads and Windows boxes, it seems to me to cut to the heart of several problems, and I'm willing to say that Python threading doesn't work anymore on other boxes until platform wizards volunteer code to implement this API there too. Since the start, Python threading has been constrained by the near-empty intersection of what even the feeblest platform thread implementations supply, and that creates problems without real payback. Let 'em eat Stackless <wink>.