[Python-Dev] Final PEP 311 run

[Mark Hammond]

Hi all,
 I'd like to get PEP311 in for the Python 2.3b1 -
http://www.python.org/peps/pep-0311.html (or even if I miss, very soon
after!)

There appears to be no issues with the technical aspects of the PEP (please
correct me now if I am wrong).  The only issue is the name of the API.

To save re-reading the PEP just to understand the names, I will summarize
here (see the PEP for the full version):

There are 2 new functions, called as a pair.  The first function sets up the
Python thread state, along with the GIL, so that the current thread can
safely call the Python API.  The function makes no assumptions about the
current state of the GIL etc - it works out the current state, and does the
"right thing".  The second function is the reverse of the first, to indicate
that the thread has finished with the thread state for the time being.

The PEP calls these functions PyAutoThreadState_Ensure() and
PyAutoThreadState_Release()

Reasons for the names in the PEP:
"Auto" reflects that the current thread-state need not be known (whereas the
other APIs do).  "Ensure()" reflects that nothing may actually be
*created* - all we are doing is "ensuring" we have the resources, creating
only if necessary. On the down-side - "Auto" will look strange in the future
when this is the standard way of managing the lock.  "ThreadState" does not
reflect that the function does more than manage the PyThreadState - it also
manages the locks (which while an implementation detail, are currently
discrete)

Other Proposals:
     Just: PyGIL_Ensure(), PyGIL_Release(): shorter to type, conveys the
meaning.
     David Abrahams: Prefers SubjectVerbObject, so would prefer
"PyEnsureGIL" - but likes
     PyAcquireInterpreter() and PyReleaseInterpreter() best.
     Dropping "Auto" from the PEP gives PyThreadState_Ensure() and
PyThreadState_Release().

I admit to liking "PyAcquireInterpreter()" best, but it does not match the
existing API structure.  For the sake of typing, I would be happy to go with
Just's PyGIL_Ensure(), but maybe PyInterpreter_Ensure() is a good
compromise.

Other opinions or pronouncements welcome :)

Mark.