On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood <bruce.sherw...@gmail.com> wrote: > (2) My hand is forced by Apple no longer supporting Carbon. Among > other aspects of this, Carbon can't be used with 64-bit Python, and > more and more Mac users of VPython want to use 64-bit Python. So there > has to be a version of VPython that is based on Cocoa, but Cocoa is > required to be the primary thread. This requirement, combined with the > absolute requirement that the VPython API cannot be changed, is the > problem I face. I have to turn the architecture inside out, > independent of whether the solution meets all criteria for good Python > programming style.
I had exactly this problem with Tkinter on Mac. The API involved "synchronous" calls to update a GUI written in tkinter, which ran in another thread (so e.g. students could call the API from the interactive interpreter). This didn't work on new Mac OS X releases, because Tkinter had to be run in the main thread after some update -- and also because of this deadlock issue with imports (but I didn't know that until later). I ended up solving it by running the Tkinter in the main thread of a different process, which could handle RPC invocations asynchronously, and sending remote invocations via a synchronous RPC library in the parent process. Maybe you can do something similar in your case? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
