I just started looking over the GIL pep http://www.python.org/peps/pep-0311.html. Looks pretty nice to me so far! I have these remarks:

Great!

"This API will not perform automatic initialization of Python, or initialize Python for multi-threaded operation. Extension authors must continue to call Py_Initialize(), and for multi-threaded applications, PyEval_InitThreads()."

This is liable to confuse people (like me) who have never had to do Py_Initialize or PyEval_InitThreads in their extension modules.

Good point. I will change "Extension Authors" to "Applications which embed Python"

"It is intended that this API be all that is necessary to acquire the Python GIL. Apart from the existing, standard Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros, it is assumed that no additional thread state API functions will be used by the extension. Extensions with such complicated requirements are free to continue to use the existing thread state API."

This sounds like it's saying you can't use any of the old thread API functions if you use the new ones. Is that right? If so, I think it should be made more explicit. Seems a bit draconian, though I admit I don't know what other thread API functions people might want.

That is kind-of what I mean <wink>. My concern is simply that I did not want to make this code totally bullet-proof in the face of all the tricks that can be pulled with the existing thread-state API. For example, the existing API allows you to switch as many different thread-states in for a single thread that you desire. I am really not sure what my patch would do if the developer goes and swaps thread-states underneath our API. I guess all I am saying is: If you use other thread-state APIs in conjunction with this new API, it is your responsibility to make sure everything works!

Good job, Mark!

Thanks! And while we are here, do you have any suggestions for the name, as per the start of the PEP? I am starting to think PyThreadState_Ensure() and PyThreadState_Release() are good enough names. The only problem is that they are not really part of the same "family" as the other PyThreadState_* functions, and thus people may assume they can mix-and-match them. OTOH, they clearly are ThreadState related functions, so are at least cousins to the rest of them! As far as I can tell, there are no technical issues remaining in this PEP - only naming and clarification. Does anyone disagree with that? Keen-to-get-this-in-2.3 ly, Mark.