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

[gandreas@gandreas.com]

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.

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

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


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