Hi Ronald,

thanks for your quick answer!

The former actually sounds like exactly what I'd need.
Just one more question: Given that my python script is stored inside an NSString property,
what actions/functions would would I need to run before being able to instantiate one of the python clases?
After all the Python would have to have been run before I'd be be able to instantiate one of its subclasses, no?

Would something like this be the right way?

#import <Python.h>


@protocol PythonClassProtocol
@optional
- (BOOL)shallRejectObject:(NSObject *)object;
@end


Py_Initialize();
PyRun_SimpleString([self.script UTF8String])
Py_Finalize();

id<PythonClassProtocol> pythonObject = [[NSClassFromString(@"PythonClass") alloc] init];

for (id<PythonClassProtocol> object in self.objects) {
if ([pythonObject shallRejectObject:object]) {
[self rejectObject:object];
}
}

Oh and what if the user (me) runs the Python script once, edits it and runs it again?
Any conflicts to be expected, given that a class of that name (with potentially different logic, of which I'd obviously want to use the new one) has been created before?
If the latter was the case would I have to extract my filtering routine (not just the filtering method, but the entire code as seen above) into
its own NSTask being re-launched on every execution and talk to my own app via some kind of bridge of my own (Distributed Objects, what not)?

Thanks a bunch,
Vincent

On May 21, 2012, at 8:02 AM, Ronald Oussoren wrote:

Using Python from ObjC like this is suboptimal at the moment, mostly because I don't use PyObjC in that way. I'd define an stub class with the right interface in Objective-C with a subclass in Python that implements that interface. That way you can fetch the Python class using objc_lookUpClass (or the Foundation wrapper around that function), create an instance and then call the methods without getting compiler warnings.

To expose instances you have to define an API to fetch those instances.

Ronald