More PyObjC Trunk News

• PyObjCTools.AppHelper.runEventLoop() will now bring your application to the front at startup when using pdb mode for convenience.
• objc.loadBundle() no longer filters the class list. This solves a few potential issues and shaves off about 1/3rd of the overhead of python -c "import AppKit".
• PyObjCTools.AppHelper.runEventLoop() no longer breaks on pure Objective-C exceptions. Most exceptions of this variety are more like warnings, and there is nothing that can be done them anyway.
• PyObjCTools.AppHelper.runEventLoop() now installs the interrupt handler and verbose exception logging when using pdb, either explicitly or by the USE_PDB environment variable.

I've also made some more progress on the (still marked NonFunctional) RemotePyInterpreter example. It starts up and works, but stdin is not fully implemented and completion is not available. As Cocoa expects completion to be synchronous, completion will be a little bit tricky to implement. I'll probably have it return no completions, and then trigger a completion after the results are available (if they came back fast enough, I guess?). After the interpreter is done, I'll see about writing a remote object browser (you can probably guess where this is eventually leading...).

After doing some optimization of PyObjC's initialization I started thinking about what else can be done to increase performance and offer more flexibility. I think the key to this is making PyObjC as lazy as possible. This might mean the return of an objc.runtime equivalent? Also, I'm not so sure about creating all of these selector objects so eagerly. Why bother? pydoc support for Objective-C classes is basically worthless anyway because there are no doc strings. I suppose we could have the dict-proxy object do the eager lookup if someone tries to iterate over it (more for code completion than pydoc), but I don't see a good reason to bother until you at least poke the class. This kind of laziness may also be the key to solving the infamous bug where you can't reasonably use a class method on a class that has an instance method of the same selector. There is a way, but I think it might crash if the class and instance selectors have different type signatures (though this would be rare if it even exists).