On May 31, 2005, at 2:36 PM, [EMAIL PROTECTED] wrote: > > On May 31, 2005, at 3:51 PM, Bob Ippolito wrote: > > >> >> On May 31, 2005, at 1:17 PM, [EMAIL PROTECTED] 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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
