[Pythonmac-SIG] PyObjC vs "old school" embedding
gandreas@gandreas.com
gandreas at gandreas.com
Wed Jun 1 00:41:56 CEST 2005
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
More information about the Pythonmac-SIG
mailing list