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

[Bob Ippolito]

On May 31, 2005, at 3:41 PM, gandreas at gandreas.com wrote:

>
> 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).

Possibly, but I don't think that's the problem.

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

Yeah, most likely.

> 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...

I doubt it..

The recommended method is to create a plugin bundle, not to use the  
Python C API.  There is no good reason to use the Python C API from  
an Objective-C application unless you already went down that road..  
which, is basically your application, and little else (if anything).   
I still think you should change your app to do it sanely.

> 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...

Do what's done in the bundle template stub for intiialization, and do  
PyGILState_Ensure() before calling any Python code, and  
PyGILState_Release() afterwards.

Better yet, use a bundle.

-bob