I'll start with a word of warning: the pyobjc API is not yet public yet. This will change for the next release, hopefully without backward compatible changes.
What you need to do:
* copy Modules/objc/pyobjc-api.h into your project (our add that directory to your project).
* read pyobjc-api.h
* after you initialize the interpreter call PyObjC_ImportAPI to import the objc module (don't forget to #include pyobjc-api.h)
* use the API-functions
The API currently has one major problem: it can only be used in a single file. If you want to use the API in multiple objc-files you either have to hack around this or call PyObjC_ImportAPI in every file. I'd hack around this limitation ;-). I'll see if I can add a documented way to use the API from multiple objc-files in the next release.
BTW. Your call to PyRun_String will probably not work, I'd not be surprised if the locals and globals dicts must be "real" python dictionaries (e.g. of type PyDict_Type).
Ronald
On Tuesday, July 20, 2004, at 06:31PM, Jonathan Wight <jwight@...> wrote:
>On Jul 20, 2004, at 11:42, Bob Ippolito wrote:
>
>>> But I'd imagine all the objects (standard Foundation objects) I need
>>> already work? So this effort is just for custom classes?
>>
>> *ALL* objects work. The problem is that not all selectors are
>> guaranteed to work out of the box if they take
>> pointers-to-things-other-than-objects arguments.
>
>Which is understandable.
>
>>> For Foundation objects Bob's PyObjC_IdToPython() seems ideal. The
>>> trouble is accessing it. Looking at the examples doesn't help - they
>>> all seem to be bundlebuilder based and I don't want the python binary
>>> to be my application's binary. The template created projects seem to
>>> be a better proposition - but I don't understand why python is loaded
>>> via NSAddImage and symbols looked up explicitly instead of just
>>> linking to Python.framework.
>>
>> It does linking itself so that:
>> - the executable stub only needs to be compiled once, ever, if you're
>> not using any additional ObjC code (not currently used in practice)
>> - the app can give a useful GUI error dialog if the BSD subsystem
>> isn't installed (which means Python.framework doesn't exist)
>> - the app can give a useful GUI error dialog if the app is run on the
>> wrong version of Mac OS X
>> .. among other reasons that are harder to explain.
>
>OK. Well I'm failing to find a solution here then. I've tried this
>snippet of code, which dies with EXC_BAD_ACCESS at PyObjC_IdToPython():
>
>Py_Initialize();
>PyRun_SimpleString("import objc");
>PyRun_SimpleString("print dir(objc)");
>
>NSDictionary *theLocals = [NSDictionary dictionaryWithObjectsAndKeys:
>@"Hello World", @"myLocal", NULL];
>PyObject *thePyLocals = PyObjC_IdToPython(theLocals);
>PyObject *theObject = PyRun_String("print '>>>', myLocal", 0, NULL,
>thePyLocals);
>NSLog(@">> %@", PyObjC_PythonToId(theObject));
>
>So forgive me if I'm being dense - I'm not getting what you and Bill
>are suggesting. Converting my project into a pure PyObjC project
>instead of trying to embed it isn't really an option at this stage.
>
> Jon.
>
|