[David]
I think I'm done arguing about this. If Mark isn't discouraged by now, I'm still ready to help with the PEP.
No, I saw this coming a mile off :) A little like clockwork really. Martin seems to be trying to make 3 points: 1) There is no problem. All Windows API function that could indirectly send a Windows message are clearly documented that they generate messages, and if they arent then it is all MS' fault anyway. Substitute "Windows" and "MS" for the particular problem you are having, and we have a nice answer to every potential problem :) 2) Even if such a problem did exist, then creating a brand new thread-state for each and every invocation is acceptable. 3) Mark stated performance was secondary to correctness. Therefore, as soon as we have correctness we can ignore performance as it is not a primary requirement. (1) is clearly bogus. As with David, I am not interested in discussing this issue. 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). All due respect Martin, but stick to where your expertise lies. As for (2): My understanding (due to the name of the object) is that a single thread should use a single thread-state. You are suggesting that the same thread could have any number of different thread-states, depending on how often the Python interpreter was recursively entered. While I concede that this is likely to work in the general case, I am not sure it is "correct". If no threading semantics will be broken by having one thread use multiple thread-states, then I must ask what purpose thread-states (as opposed to the GIL) have. Mark.