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

[Bob Ippolito]

On May 31, 2005, at 2:36 PM, gandreas at gandreas.com wrote:

>
> On May 31, 2005, at 3:51 PM, Bob Ippolito wrote:
>
>
>>
>> On May 31, 2005, at 1:17 PM, gandreas at gandreas.com wrote:
>>
>>
>>
>>> So PyOXIDE is based on the traditional way to embed python in an  
>>> application (explicitly calling the python APIs to access and  
>>> call stuff), and this worked reasonably well.  For example, it  
>>> runs various scripts at startup, which register various callbacks  
>>> to handle things like new documents, new interactives, etc...  
>>> (and then the underlying Objective C code explicitly calls these  
>>> callbacks at appropriate points).
>>>
>>>
>>
>> I would just throw this stuff away and take advantage of what  
>> PyObjC can (and has always been able to) do for you.  Digging at  
>> the Python API is hard to get right, and is a LOT more code, as  
>> you've shown.
>>
>
> Yes, it's trickier to get all the details correct on embedding, but  
> yes, I've done it before (more times than I care to admit) so it  
> wasn't that big of a deal.  However, the current release of PyObjC  
> appears to change the semantics of that - what  the current  
> interpreter state is when getting called back has changed, so it is  
> no longer possible to explicitly call further Python code via the  
> embedding API from native code called over the PyObjC bridge.

It hasn't really changed, you just weren't managing the interpreter  
state correctly.

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

>> but I HIGHLY RECOMMEND that you throw away all your Python C API  
>> code and use a PyObjC-based bundle instead, which will take care  
>> of managing interpreter state and such for you at message dispatch  
>> boundaries.
>
> It's just not practical at this time to "throw away all my Python C  
> API code" and refactor the application to be a PyObjC based bundle,  
> and frankly, I don't consider this a practical answer anyway.   
> Saying "yes, you can embed python and PyObjC but you really want to  
> throw things around and have your application embedded as a PyObjC  
> based bundle" seems to be a limiting answer.  There's lots of  
> scripting languages that can be embedded with various levels of  
> language bridges - Python (PyObjC), Perl (CamelBones), JavaScript  
> (WebKit), Lua (LuaObjective-C), Ruby (RubyCocoa) etc... and as near  
> as I know, PyObjC is the only one that requires this "embed your  
> app" approach.

PyObjC-based bundle meaning -- PyObjC-based *plugin* MH_BUNDLE!!

I didn't say rewrite the shell of your app.

> PyObjC and the whole py2app is a _great_ way to take python scripts  
> and turn them into an application - don't get me wrong, I'm not say  
> this isn't really slick and amazing with how well it works, but  
> this doesn't seem like a good approach to embedding Python in an  
> existing application.  Compare it with how to use Javascript via  
> WebKit - yes, it's no where near as flexible/automatic as PyObjC,  
> (and you can't mix and match inheritance!) but in the end, if you  
> want to embed a scripting language to extend your application,  
> Javascript via Webkit is probably a better solution than PyObjC  
> (which is a real shame).

If you say so..

-bob