Re: [Pyobjc-dev] PythonBrowser example/study + bug report

[Ronald O. <ous...@ci...>]

On Sunday, Dec 1, 2002, at 21:55 Europe/Amsterdam, Just van Rossum 
wrote:

>> 2) The exception raised when converting from Python to Objective-C
>> exceptions should always include the file+line where the exception
>> was raised.
>
> It can't include a proper traceback? (Sorry if this is naive, I know 
> nothing
> about exceptions in ObjC yet.)

That's another possibility, is there a function to translate a 
traceback to a string (PyErr_Print writes to a file)?


>
>> BTW. 'objc.setVerbose' should IMHO be a property ('objc.verbose = 1'
>> instead of 'objc.setVerbose(1)'), but I'm pretty sure that it is
>> impossible to add properties to a module without subclassing
>> types.ModuleType. This is too bad because module-properties would be a
>> neat way to proxy global variables in Objective-C frameworks.
>
> What about an object in the module with a special name, handling the 
> access to
> globals?
>
> On the other hand: wouldn't subclassing the module class also be an 
> opportunity
> to speedup loading of Foundation and AppKit by doing things lazily? 
> Oh, I don't
> think we need to subclass module at all: we can just inject an 
> arbitrary object
> into sys.modules; I just tried it, and even "from FakeModule import *" 
> works
> just fine.

But wouldn't 'from AppKit import *' stop working if the AppKit 'module' 
creates the proxies lazily? I've done some experiments to find why 
importing AppKit is as slow as it is. Actually loading the framework 
isn't that expensive, the problem is really in creating all proxy 
classes and specifically in walking the method-tables of Objective-C 
classes. I'll check if I can somehow postpone this until it is really 
needed (someone doing dir(NSObject) or creating an instance of the 
proxy [or one of its subclasses]).

My local tree is already somewhat faster by somewhat optimizing 
existing code and moving the actual loading code to Objective-C.

Ronald