hi,
if I would set up a fresh machine with Xcode 5.0 and 10.9 should this support PyObc?
I tried this a few months ago and failed to make it work, just wondering if anyone else tried it lately.
I'm currently on Xcode 4.6.3 and 10.8.5 and build pyobjc from source code.
marc

On 19 dec. 2013, at 13:42, Ronald Oussoren <ronaldoussoren@...> wrote:
>>
>> Is there something in the nature of pyobjc objects that makes them confuse dockets?
>
> Not sure if the class repr at the top of the traceback is relevant, but if it is this might be due to doctest trying to test some PyObjC classes.
>
> BTW. I’m moving away from “from AppKit import *” towards just importing what I need. That leads to code that’s slightly easier to check with linting tools, and in recent versions of PyObjC is faster as well because the framework wrappers now try to do as little work as possible (and that doesn’t work when you import everything).
I finally got around to rewriting the tests, for completeness' sake I can confirm that switching
from AppKit import *
to just the items I need allows the doctests to run. Thanks!
E

On 19 Feb 2014, at 00:23, Ian McCullough <ipmcc@...> wrote:
> Hi,
>
> I'm trying to determine the best way to expose custom, application-specific, non-system-framework (i.e. not in one of the framework wrappers provided with PyObjC) classes written in Objective-C to python across the PyObjC bridge. My eventual hope is to develop a "hybrid" application in which some portions of the app are in Objective-C and others are in python, with the two side integrating via the PyObjC bridge. Most of the documentation I've been able to find seems to focus on situations where the goal is to have all the app-specific code be in python, and to have the python call out to AppKit classes, etc via the bridge and the pre-packaged system framework wrappers.
>
> I've not seen any indication that it's possible to expose classes from an app. But I did find this web page: https://pythonhosted.org/pyobjc/dev/wrapping.html which makes it sound like the best way would be for me to move any classes that need to be visible to python out of my application, and into a framework (which I can embed in my application), and then to adapt an existing framework wrapper to wrap this newly-created framework. So far, the wrapper-adapting part is proving to be easier said that done.
>
> Looking at the existing wrappers, many of them have a compiled component (i.e. .m files). As far as I can tell, that seems to be responsible for bringing in protocols, constants and C functions. That said, it's not clear to me what all triggers the need for a compiled extension. I also saw that the _metadata.py files in existing wrappers have this at the top of them: "This file is generated by objective.metadata". I tracked that down to this repo: https://bitbucket.org/ronaldoussoren/objective.metadata which, with some coaxing I could get to build, install and run, but I've not gotten it to do anything useful yet -- i.e. how I get it to generate these _metadata.py files is not obvious.
>
> I'm content to keep fighting through the source on my own, but there's this part of my mind saying, "You've *got* to be missing something. It can't possibly be this involved to expose a framework to python." I can understand the overhead for exposing C functions and constants, but all the Objective-C stuff should be doable at runtime, right?
That’s correct. The metadata is only needed to expose C functions, constants, C type definitions (e.g. “NSRect”) and the API for methods where the API cannot be fully extracted from the Objective-C runtime. The latter are methods that have pointer arguments (excluding “id”), as the bridge cannot know what’s supposed to be passed there (input or output, 1 value or an array of some size, …)
>
> So, in sum:
>
> 1) Is this the right way to expose Objective-C classes to Python?
The framework wrappers are an example of the most comprehensive way to expose Objective-C APIs to Python. If that is the best way for you depends on the amount and complexity of the code you want to expose to python.
>
> Assuming yes...
>
> 2) Exhaustively speaking, what triggers the need for a compiled extension?
* Protocols
* Methods and functions that cannot be represented using metadata
> 3) What is the magic invocation to get objective.metadata to spit out the _metadata.py files for my framework?
> 4) Any other tips that might help in with this "hybrid" app goal?
>
> Many thanks,
> Ian
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

On 17 Feb 2014, at 20:34, Ian McCullough <ipmcc@...> wrote:
> Yeah, I'm not delusional enough to think that the whole NS* world would magically be pickle-able, but it seemed within the realm of possibility that I could implement pickling for the small subset of classes that comprised my model.
That should be possible, that is Objective-C objects can be pickled if you implement __reduce__ for their classes. It is not possible to pickle arbitrary Objective-C objects, not even the subset implementing NSCoding.
> It still does seem like a reasonable proposition, but I'm seeing enough squirrelly behavior between the stackless interpreter and pyobjc right off the bat, that I'm sort of hesitant to press onward. The first thing was the fact that PyHeapTypeObject is the same as PyTypeObject in stackless, so I had to go through and remove all the places that accessed the ht_type of PyHeapTypeObject. A straightforward change, to be sure, but then I started seeing lots of weirdness at run time (lots of null-ptr dereferences around the python <-> pyobjc boundaries that made no sense). I might have been willing to bite off the task of maintaining a vendor branch of pyobjc for running with stackless python, but I don't want to end up maintaining a vendor branch of stackless as well, so…
Patches to make PyObjC work with Stackless would be appreciated as long as they are not too invasive (and actually work). I don’t use Stackless myself and hence have never tested with it.
BTW. You’re bound to run into problems if Stackless still copies the C stack to switch between tasks and you switch tasks where one of the tasks has calls to Objective-C on the stack.
>
> As far as serializing execution state, the classic native approach would be to break the code down into a state machine, and then serialize the state machine. For non-trivial code (you know, anything with loops or subroutines, etc), breaking it down into a state machine becomes tedious. Not using python also eliminates the scripty-ness/dynamism of using python. By using python to implement the logic and flow, it becomes that much easier to experiment with minor variations in the logic, etc.
>
> Oh well... I might bang on it a little more to see what I can see, but I assume that if someone on this list were up and running with pyobjc and stackless they would have posted by now…
I wouldn’t count on that at all :-). Have you asked on the stackless list about this?
Ronald
>
> Thanks,
> Ian
>
>
> On Sun, Feb 16, 2014 at 3:57 PM, Diez B. Roggisch <deets@...> wrote:
> I thought it was something along these lines.
>
> I guess all you can do is to set up your "host" application in a way that it can restore the save-game state from scratch, regardless of what that state currently is.
>
> But hoping that the whole NS*-world is persistable is bound to be disappointing :)
>
> Diez
>
> On Feb 16, 2014, at 9:28 PM, Ian McCullough <ipmcc@...> wrote:
>
>> The idea is to have a native Objective-C app, which hosts a stackless python interpreter in-process. The main feature of interest to me is the ability of stackless python to serialize a tasklet and deserialize and resume it later. Think of it as a "save game" mechanism, where the game logic is implemented in python -- you can save your game by serializing the state of the tasklet, and restore it later.
>>
>> The usage of pyobjc was intended to keep from having to keep a python-side model and a native-side model in sync.
>>
>> FWIW, I actually managed to get pyobjc to compile against stackless with some slight modifications, but I'm seeing some real weird behavior at runtime, so I'm not holding out much hope.
>>
>> Ian
>>
>>
>>
>> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <deets@...> wrote:
>> As long as objective C isn't stackless, I doubt there is much use to it. What's your purpose?
>>
>> Diez
>>
>> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ipmcc@...> wrote:
>>
>> >
>> > Is it possible to build PyObjC for use with Stackless python? My attempts are pointing to "No" but I figured I'd ask.
>> > Thanks,Ian
>> >
>> > ------------------------------------------------------------------------------
>> > Android apps run on BlackBerry 10
>> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> > Get your Android app in front of a whole new audience. Start now.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> > Pyobjc-dev mailing list
>> > Pyobjc-dev@...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> Pyobjc-dev mailing list
>> Pyobjc-dev@...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

(Sorry about the top posting, I'm posting through iCloud webmail and that tends to mangle mails to mailinglist in interesting ways...)
The framework wrappers don't contain that much intelligence, at first approximation a wrapper module for your own code can do something like:
# MyClasses.py
import objc
# ... arrange for loading your code (if necessary)
for cls in objc.getClassList():
globals()[cls.name] = cls
That way your classes are available in the MyClasses namespace. Then add definitions for globals symbols and the like.
The metadata tools are at best under-documented, and is very, very fragile (and didn't work at all for me on the 10.9 headers). I'm trying to rewrite the parsing code using the python interface to clang.cindex, but that is moving forward fairly slowly because there is very little documentation on clang.cindex.
At the moment it might be easier to just create an _metadata.py file manually instead of using the metadata tool (assuming your headers don't contain a lot of definitions that need to be added to the metadata file)
Ronald
On Feb 19, 2014, at 03:07 PM, Ian McCullough <ipmcc@...> wrote:
Ken & Georg,
Thanks for your replies.
I've already gotten this far -- i.e. I'm running the interpreter in process, executing arbitrary python scripts in it, and trading objects back and forth via NSClassFromString and other API with provided wrappers. What I was hoping to achieve was "first-class" support for my classes -- like the framework wrappers that ship with PyObjC for the system frameworks.
I've made some progress by brute force. I've gotten objective-metadata-tool installed, and I'm currently working through getting it to scan my framework's headers. This process appears under-documented, so my experience is basically, "Try an invocation of objective-metadata-tool in the debugger. See what fails. Figure out why it failed. Adjust invocation to avoid that condition. Repeat." I'll report back with my findings if I have any eventual success.
Thanks,
Ian
On Wed, Feb 19, 2014 at 2:56 AM, Ken Thomases <ken@...> wrote:
On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
> I'm trying to determine the best way to expose custom,
> application-specific, non-system-framework (i.e. not in one of the
> framework wrappers provided with PyObjC) classes written in Objective-C to
> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
> application in which some portions of the app are in Objective-C and others
> are in python, with the two side integrating via the PyObjC bridge. Most of
> the documentation I've been able to find seems to focus on situations where
> the goal is to have all the app-specific code be in python, and to have the
> python call out to AppKit classes, etc via the bridge and the pre-packaged
> system framework wrappers.
>
> I've not seen any indication that it's possible to expose classes from an
> app.
It is. I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework. You would then use the Python embedding API to set up the Python runtime and load and run some Python code. You might do something like:
NSString* pythonPath = /* path within your app bundle to its Python files */;
setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
Py_InitializeEx(0);
PyEval_InitThreads();
PyGILState_STATE gilState = PyGILState_Ensure();
NSString* script = /* path to a initialization script in your app bundle */;
static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
static char** argv = &arg0; // ditto
PySys_SetArgv(1, argv);
FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
if (result) /* handle error */;
PyGILState_Release(gilState);
if (gilState == PyGILState_LOCKED)
{
PyThreadState_Swap(NULL);
PyEval_ReleaseLock();
}
The script file mentioned above would just import modules and do initialization and then exit. It wouldn't be a long-running script. Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.
After that, you have a few ways of interacting between the Python code and the Objective-C code. Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime. It can be looked up with NSClassFromString(). Then, it's methods can be invoked directly. You can make that simpler by declaring Objective-C interfaces for those classes.
The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.
Also, the Python code can find some objects itself, such as NSApp or various singletons. It can then do things like set itself as delegates or register for notifications.
I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts. If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.
I hope that helps.
Cheers,
Ken
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Pyobjc-dev mailing list
Pyobjc-dev@...
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Ken & Georg,
Thanks for your replies.
I've already gotten this far -- i.e. I'm running the interpreter in
process, executing arbitrary python scripts in it, and trading objects back
and forth via NSClassFromString and other API with provided wrappers. What
I was hoping to achieve was "first-class" support for my classes -- like
the framework wrappers that ship with PyObjC for the system frameworks.
I've made some progress by brute force. I've gotten objective-metadata-tool
installed, and I'm currently working through getting it to scan my
framework's headers. This process appears under-documented, so my
experience is basically, "Try an invocation of objective-metadata-tool in
the debugger. See what fails. Figure out why it failed. Adjust invocation
to avoid that condition. Repeat." I'll report back with my findings if I
have any eventual success.
Thanks,
Ian
On Wed, Feb 19, 2014 at 2:56 AM, Ken Thomases <ken@...> wrote:
> On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
>
> > I'm trying to determine the best way to expose custom,
> > application-specific, non-system-framework (i.e. not in one of the
> > framework wrappers provided with PyObjC) classes written in Objective-C
> to
> > python across the PyObjC bridge. My eventual hope is to develop a
> "hybrid"
> > application in which some portions of the app are in Objective-C and
> others
> > are in python, with the two side integrating via the PyObjC bridge. Most
> of
> > the documentation I've been able to find seems to focus on situations
> where
> > the goal is to have all the app-specific code be in python, and to have
> the
> > python call out to AppKit classes, etc via the bridge and the
> pre-packaged
> > system framework wrappers.
> >
> > I've not seen any indication that it's possible to expose classes from an
> > app.
>
> It is. I don't know if this is the best way, but one way is to link an
> otherwise ordinary Cocoa app, written in Objective-C, to the Python
> framework. You would then use the Python embedding API to set up the
> Python runtime and load and run some Python code. You might do something
> like:
>
> NSString* pythonPath = /* path within your app bundle to its Python
> files */;
> setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
>
> Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of
> Python you link against; don't know how relevant this is
> Py_InitializeEx(0);
> PyEval_InitThreads();
> PyGILState_STATE gilState = PyGILState_Ensure();
>
> NSString* script = /* path to a initialization script in your app
> bundle */;
> static char* arg0 = strdup([script fileSystemRepresentation]); //
> don't deallocate until Python runtime is terminated, if ever
> static char** argv = &arg0; // ditto
> PySys_SetArgv(1, argv);
>
> FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
> int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script
> lastPathComponent] fileSystemRepresentation], 1);
> if (result) /* handle error */;
>
> PyGILState_Release(gilState);
> if (gilState == PyGILState_LOCKED)
> {
> PyThreadState_Swap(NULL);
> PyEval_ReleaseLock();
> }
>
> The script file mentioned above would just import modules and do
> initialization and then exit. It wouldn't be a long-running script. Since
> the application keeps running and the Python runtime is persistent, the
> state which is set up by the script persists, too.
>
> After that, you have a few ways of interacting between the Python code and
> the Objective-C code. Any Python class which inherits from a Cocoa class
> is registered with the Objective-C runtime. It can be looked up with
> NSClassFromString(). Then, it's methods can be invoked directly. You can
> make that simpler by declaring Objective-C interfaces for those classes.
>
> The Objective-C code can pass its objects into the methods of the Python
> classes and the Python code can then operate on those objects.
>
> Also, the Python code can find some objects itself, such as NSApp or
> various singletons. It can then do things like set itself as delegates or
> register for notifications.
>
> I believe that the classes of your app, since they were registered with
> the Objective-C runtime at the time that Python was loaded and your
> initialization script was run, can just be used directly in your Python
> scripts. If that doesn't work, I'm sure you can use
> Foundation.NSClassFromString() to get access.
>
> I hope that helps.
>
> Cheers,
> Ken
>
>

Hi,
I use python in my app a lot. The App is written in ObjectiveC but it can run python scripts.
The only thing I needed to do is to link to the python framework and run Py_Initialize(); once.
Then I run some python code like this:
PyGILState_STATE gilState = PyGILState_Ensure();
PyRun_SimpleString( "Some initializer code" );
PyGILState_Release(gilState);
Best
Georg Seifert
Am 19.02.2014 um 08:56 schrieb Ken Thomases <ken@...>:
> On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
>
>> I'm trying to determine the best way to expose custom,
>> application-specific, non-system-framework (i.e. not in one of the
>> framework wrappers provided with PyObjC) classes written in Objective-C to
>> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
>> application in which some portions of the app are in Objective-C and others
>> are in python, with the two side integrating via the PyObjC bridge. Most of
>> the documentation I've been able to find seems to focus on situations where
>> the goal is to have all the app-specific code be in python, and to have the
>> python call out to AppKit classes, etc via the bridge and the pre-packaged
>> system framework wrappers.
>>
>> I've not seen any indication that it's possible to expose classes from an
>> app.
>
> It is. I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework. You would then use the Python embedding API to set up the Python runtime and load and run some Python code. You might do something like:
>
> NSString* pythonPath = /* path within your app bundle to its Python files */;
> setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
>
> Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
> Py_InitializeEx(0);
> PyEval_InitThreads();
> PyGILState_STATE gilState = PyGILState_Ensure();
>
> NSString* script = /* path to a initialization script in your app bundle */;
> static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
> static char** argv = &arg0; // ditto
> PySys_SetArgv(1, argv);
>
> FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
> int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
> if (result) /* handle error */;
>
> PyGILState_Release(gilState);
> if (gilState == PyGILState_LOCKED)
> {
> PyThreadState_Swap(NULL);
> PyEval_ReleaseLock();
> }
>
> The script file mentioned above would just import modules and do initialization and then exit. It wouldn't be a long-running script. Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.
>
> After that, you have a few ways of interacting between the Python code and the Objective-C code. Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime. It can be looked up with NSClassFromString(). Then, it's methods can be invoked directly. You can make that simpler by declaring Objective-C interfaces for those classes.
>
> The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.
>
> Also, the Python code can find some objects itself, such as NSApp or various singletons. It can then do things like set itself as delegates or register for notifications.
>
> I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts. If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.
>
> I hope that helps.
>
> Cheers,
> Ken
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
> I'm trying to determine the best way to expose custom,
> application-specific, non-system-framework (i.e. not in one of the
> framework wrappers provided with PyObjC) classes written in Objective-C to
> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
> application in which some portions of the app are in Objective-C and others
> are in python, with the two side integrating via the PyObjC bridge. Most of
> the documentation I've been able to find seems to focus on situations where
> the goal is to have all the app-specific code be in python, and to have the
> python call out to AppKit classes, etc via the bridge and the pre-packaged
> system framework wrappers.
>
> I've not seen any indication that it's possible to expose classes from an
> app.
It is. I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework. You would then use the Python embedding API to set up the Python runtime and load and run some Python code. You might do something like:
NSString* pythonPath = /* path within your app bundle to its Python files */;
setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
Py_InitializeEx(0);
PyEval_InitThreads();
PyGILState_STATE gilState = PyGILState_Ensure();
NSString* script = /* path to a initialization script in your app bundle */;
static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
static char** argv = &arg0; // ditto
PySys_SetArgv(1, argv);
FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
if (result) /* handle error */;
PyGILState_Release(gilState);
if (gilState == PyGILState_LOCKED)
{
PyThreadState_Swap(NULL);
PyEval_ReleaseLock();
}
The script file mentioned above would just import modules and do initialization and then exit. It wouldn't be a long-running script. Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.
After that, you have a few ways of interacting between the Python code and the Objective-C code. Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime. It can be looked up with NSClassFromString(). Then, it's methods can be invoked directly. You can make that simpler by declaring Objective-C interfaces for those classes.
The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.
Also, the Python code can find some objects itself, such as NSApp or various singletons. It can then do things like set itself as delegates or register for notifications.
I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts. If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.
I hope that helps.
Cheers,
Ken

Hi,
I'm trying to determine the best way to expose custom,
application-specific, non-system-framework (i.e. not in one of the
framework wrappers provided with PyObjC) classes written in Objective-C to
python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
application in which some portions of the app are in Objective-C and others
are in python, with the two side integrating via the PyObjC bridge. Most of
the documentation I've been able to find seems to focus on situations where
the goal is to have all the app-specific code be in python, and to have the
python call out to AppKit classes, etc via the bridge and the pre-packaged
system framework wrappers.
I've not seen any indication that it's possible to expose classes from an
app. But I did find this web page:
https://pythonhosted.org/pyobjc/dev/wrapping.html which makes it sound like
the best way would be for me to move any classes that need to be visible to
python out of my application, and into a framework (which I can embed in my
application), and then to adapt an existing framework wrapper to wrap this
newly-created framework. So far, the wrapper-adapting part is proving to be
easier said that done.
Looking at the existing wrappers, many of them have a compiled component
(i.e. .m files). As far as I can tell, that seems to be responsible for
bringing in protocols, constants and C functions. That said, it's not clear
to me what all triggers the need for a compiled extension. I also saw that
the _metadata.py files in existing wrappers have this at the top of them:
"This file is generated by objective.metadata". I tracked that down to this
repo: https://bitbucket.org/ronaldoussoren/objective.metadata which, with
some coaxing I could get to build, install and run, but I've not gotten it
to do anything useful yet -- i.e. how I get it to generate these
_metadata.py files is not obvious.
I'm content to keep fighting through the source on my own, but there's this
part of my mind saying, "You've *got* to be missing something. It can't
possibly be this involved to expose a framework to python." I can
understand the overhead for exposing C functions and constants, but all the
Objective-C stuff should be doable at runtime, right?
So, in sum:
1) Is this the right way to expose Objective-C classes to Python?
Assuming yes...
2) Exhaustively speaking, what triggers the need for a compiled extension?
3) What is the magic invocation to get objective.metadata to spit out the
_metadata.py files for my framework?
4) Any other tips that might help in with this "hybrid" app goal?
Many thanks,
Ian

Yeah, I'm not delusional enough to think that the whole NS* world would
magically be pickle-able, but it seemed within the realm of possibility
that I could implement pickling for the small subset of classes that
comprised my model. It still does seem like a reasonable proposition, but
I'm seeing enough squirrelly behavior between the stackless interpreter and
pyobjc right off the bat, that I'm sort of hesitant to press onward. The
first thing was the fact that PyHeapTypeObject is the same as PyTypeObject
in stackless, so I had to go through and remove all the places that
accessed the ht_type of PyHeapTypeObject. A straightforward change, to be
sure, but then I started seeing lots of weirdness at run time (lots of
null-ptr dereferences around the python <-> pyobjc boundaries that made no
sense). I might have been willing to bite off the task of maintaining a
vendor branch of pyobjc for running with stackless python, but I don't want
to end up maintaining a vendor branch of stackless as well, so...
As far as serializing execution state, the classic native approach would be
to break the code down into a state machine, and then serialize the state
machine. For non-trivial code (you know, anything with loops or
subroutines, etc), breaking it down into a state machine becomes tedious.
Not using python also eliminates the scripty-ness/dynamism of using python.
By using python to implement the logic and flow, it becomes that much
easier to experiment with minor variations in the logic, etc.
Oh well... I might bang on it a little more to see what I can see, but I
assume that if someone on this list were up and running with pyobjc and
stackless they would have posted by now...
Thanks,
Ian
On Sun, Feb 16, 2014 at 3:57 PM, Diez B. Roggisch <deets@...> wrote:
> I thought it was something along these lines.
>
> I guess all you can do is to set up your "host" application in a way that
> it can restore the save-game state from scratch, regardless of what that
> state currently is.
>
> But hoping that the whole NS*-world is persistable is bound to be
> disappointing :)
>
> Diez
>
> On Feb 16, 2014, at 9:28 PM, Ian McCullough <ipmcc@...> wrote:
>
> The idea is to have a native Objective-C app, which hosts a stackless
> python interpreter in-process. The main feature of interest to me is the
> ability of stackless python to serialize a tasklet and deserialize and
> resume it later. Think of it as a "save game" mechanism, where the game
> logic is implemented in python -- you can save your game by serializing the
> state of the tasklet, and restore it later.
>
> The usage of pyobjc was intended to keep from having to keep a python-side
> model and a native-side model in sync.
>
> FWIW, I actually managed to get pyobjc to compile against stackless with
> some slight modifications, but I'm seeing some real weird behavior at
> runtime, so I'm not holding out much hope.
>
> Ian
>
>
>
> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <deets@...> wrote:
>
>> As long as objective C isn't stackless, I doubt there is much use to it.
>> What's your purpose?
>>
>> Diez
>>
>> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ipmcc@...> wrote:
>>
>> >
>> > Is it possible to build PyObjC for use with Stackless python? My
>> attempts are pointing to "No" but I figured I'd ask.
>> > Thanks,Ian
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Android apps run on BlackBerry 10
>> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> > Get your Android app in front of a whole new audience. Start now.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> > Pyobjc-dev mailing list
>> > Pyobjc-dev@...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>

I thought it was something along these lines.
I guess all you can do is to set up your "host" application in a way that it can restore the save-game state from scratch, regardless of what that state currently is.
But hoping that the whole NS*-world is persistable is bound to be disappointing :)
Diez
On Feb 16, 2014, at 9:28 PM, Ian McCullough <ipmcc@...> wrote:
> The idea is to have a native Objective-C app, which hosts a stackless python interpreter in-process. The main feature of interest to me is the ability of stackless python to serialize a tasklet and deserialize and resume it later. Think of it as a "save game" mechanism, where the game logic is implemented in python -- you can save your game by serializing the state of the tasklet, and restore it later.
>
> The usage of pyobjc was intended to keep from having to keep a python-side model and a native-side model in sync.
>
> FWIW, I actually managed to get pyobjc to compile against stackless with some slight modifications, but I'm seeing some real weird behavior at runtime, so I'm not holding out much hope.
>
> Ian
>
>
>
> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <deets@...> wrote:
> As long as objective C isn't stackless, I doubt there is much use to it. What's your purpose?
>
> Diez
>
> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ipmcc@...> wrote:
>
> >
> > Is it possible to build PyObjC for use with Stackless python? My attempts are pointing to "No" but I figured I'd ask.
> > Thanks,Ian
> >
> > ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience. Start now.
> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> > Pyobjc-dev mailing list
> > Pyobjc-dev@...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyobjc-dev@...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

The idea is to have a native Objective-C app, which hosts a stackless
python interpreter in-process. The main feature of interest to me is the
ability of stackless python to serialize a tasklet and deserialize and
resume it later. Think of it as a "save game" mechanism, where the game
logic is implemented in python -- you can save your game by serializing the
state of the tasklet, and restore it later.
The usage of pyobjc was intended to keep from having to keep a python-side
model and a native-side model in sync.
FWIW, I actually managed to get pyobjc to compile against stackless with
some slight modifications, but I'm seeing some real weird behavior at
runtime, so I'm not holding out much hope.
Ian
On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <deets@...> wrote:
> As long as objective C isn't stackless, I doubt there is much use to it.
> What's your purpose?
>
> Diez
>
> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ipmcc@...> wrote:
>
> >
> > Is it possible to build PyObjC for use with Stackless python? My
> attempts are pointing to "No" but I figured I'd ask.
> > Thanks,Ian
> >
> >
> ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience. Start now.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> > Pyobjc-dev mailing list
> > Pyobjc-dev@...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details