[Pygui] Native wrappers?

[Dan Villiom Podlaski Christiansen]

On 14 Dec 2009, at 23:40, Greg Ewing wrote:

> Dan Villiom Podlaski Christiansen wrote:
>> Objective-C is quite dynamic and reflective. There is the problem of *types*,
>> though: All Objective-C method selectors contain an encoded type signature.
> 
> I was envisaging something ctypes-like in that you would be
> responsible for telling it what the expected argument types are.
> But very low-level details like selecting different versions of
> a function based on architecture could be automated.
> 
> There must surely be a middle ground somewhere between full-blown
> PyObjC and dealing directly with the raw ObjC runtime.

Good point. An option would be to write a proxy for a Python object/class as a new Objective-C root class implementing the NSObject protocol.[1] Whenever queried for a selector, it would somehow search the Python runtime for a matching method descriptor.

There would still be a need for converting or bridging some of the fundamental types, though. I can think of these:

* unicode ≈ NSString
* tuple ≈ NSArray
* list ≈ NSMutableArray
* dict ≈ NSMutableDictionary
* tuple? ≈ structs (e.g. NSPoint, NSRect…)

Most of this would also be needed for a less general bridge, such as the one I'm hacking on.

Of the various types, strings seem to be most used. The simple wrapper I wrote works, but it's quite far from ideal. Bridging dictionaries could be done using a slow, temporary hack that would employ ‘plistlib’ and ‘[NSDictionary description]’ to serialise in one API and de-serialise in the other.

I'm not sure about the rest of the types, except that subclassing in Cocoa may not be an option. Some of the types are implemented as so-called class clusters which don't allow subclassing. It might be preferable to implement Python types wrapping concrete Objective-C instances instead.

Concerning PyObjC, I suspect its slowness doesn't come from how it integrates with the language, but rather the fact that it instantiates all types eagerly, and does so in a fashion that corresponds almost exactly to how they are instantiated in Cocoa. This, combined with the huge headers Apple provide, results in the horrible launch times seen by it. For example, just loading the Cocoa framework does quite a lot of work up front:

% python -v -c '' |& wc -l
      97
% python -v -c 'import Cocoa' |& wc -l
     411
% python -c 'import Cocoa; print(len(dir(Cocoa)))'                       
6047

I believe PyObjC implements its wrappers based on the BridgeSupport[2] descriptions in XML. Some of the data included in the XML files is also embedded in the framework binaries, whereas other data isn't. The embedded information includes class descriptions and method selector types, but not constants and utility functions such NSMakeRange().

I've tried to gather as much information as I could on the topic, but I've come to the realisation that actually *using* the knowledge is beyond my abilities :) I hope you find my descriptions useful!

>> ‘_PyGui_NSApplication’ is an example of this, right?
> 
> Yes, that's one of them.

Did you try to implement the functionality provided by it using a delegate? Delegates seems to be the preferred in the Cocoa APIs, rather than subclassing.

For what it's worth, I have the ‘01-application’ test running now, but without actually doing anything so far :)

> Another wrinkle is that in a few places I'm faking multiple
> inheritance in subclasses of NS types by using a metaclass
> that merges class dictionaries together. Although that
> might actually become simpler if the wrappers end up being
> normal Python types that support multiple inheritance
> directly.

To be honest, I've never quite been comfortable with multiple inheritance :) I haven't used it much and regard it a bit like ‘goto’ — structures which don't suite my way of thinking.

[1] NSObject protocol reference <http://developer.apple.com/mac/library/documentation/cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html>
[2] BridgeSupport <http://bridgesupport.macosforge.org/>
--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pygui/attachments/20091215/2525e426/attachment.bin>