[Pythonmac-SIG] PyObjC vs "old school" embedding

[gandreas@gandreas.com]

On May 31, 2005, at 4:54 PM, Bob Ippolito wrote:

>>
>>> Somewhere in PyOXIDE you're not managing interpreter state  
>>> correctly, probably not in the code you've pasted, I don't have  
>>> time to look into it...
>>>
>>>
>>
>> Obviously you've got next week's session to get prepared for, but  
>> there is no code for managing the interpreter state to be wrong,  
>> since there isn't any (and without any threading, there shouldn't  
>> be the need for any - and this case is entirely threading free).
>>
>
> Actually, there is.  Look at:
> <http://svn.red-bean.com/bob/py2app/trunk/src/py2app/bundletemplate/ 
> src/main.m>

So you're saying that in order for PyObjC to work correctly, there  
must be an explicit PyEval_InitThreads call during the embedding  
code's initialization?  Because embedding "in general" (i.e., without  
threads) doesn't need to call this: <http://docs.python.org/ext/pure- 
embedding.html> (and I wasn't in previous versions - thus my comment  
about "there was no code for managing the interpreter state", since I  
was following those instructions).

And I'm assuming there must be the PyGILState_Ensure/ 
PyGILState_Release as well?

Could perhaps this sort of thing be pulled in to a  
PyObjC_InitForEmebbeding() / PyObjC_DeInitForEmbedding() routine?   
That way any additional things added in future versions could be  
encapsulated there...


How should my native script calling code (which might be called as a  
result of a callback from Python or from a purely native UI routine -  
i.e., with or without the interpreter somewhere back on the stack)  
handle the interpreter state so as to work appropriately with  
PyObjC?  Because clearly there are some unwritten assumptions here...


Glenn Andreas                      gandreas at gandreas.com
  <http://www.gandreas.com/> wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art