[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Ronald Oussoren]

On Thursday, Oct 17, 2002, at 22:06 Europe/Amsterdam, Jack Jansen wrote:

>
> On donderdag, oktober 17, 2002, at 06:24 , Bill Bumgarner wrote:
>> Convenience wrappers are in the works.  Instead of wrapping, we are 
>> thinking of simply providing a subclass of NSDictionary and NSArray 
>> that can encapsulate DictType and Array/TupleTypes respectively.
The (Objective-C) class 'OC_PythonObject' already exposes the Python 
C-API to Objective-C. It would be easy to make the interface for 
collections more like the Foundation interfaces.

There is one thing that we should keep in mind: the documentation for 
Foundation mentions that most NS<Collection> classes are binary 
compatible with CF<Collection> types (Apple uses a fancy term like 
'zero-cost bridging', they mean you can cast an NS<Collection>* to a 
CF<Collection>* and back).

I've thought about adding a mechanism that automaticly converts 
Carbon.CF.CF<Collection> instances to Objective-C objects. This is 
pretty ease, but I do not have time to do this at the moment.

>> That way, Python arrays and dicts will behave like normal NSArray / 
>> NSDictionary instances on the ObjC side of the bridge.   (The other 
>> direction has already been bridged).
>
> I think we should again combine forces here.
<nod>

> At the moment we have two bridges that make the NS-objects or the 
> CoreFoundation alter-ego's available to Python, and half a bridge the 
> other way.

>
> The Carbon.CF module (a misnomer, it isn't Carbon-dependent, that'll 
> be fixed) exports most of CoreFoundation's objects to Python, but at 
> the moment it isn't complete in that you can't say obj[12] if obj as a 
> CFArray, i.e. it just exports method calls. It does have a nifty 
> toCF() method that takes any supported Python object (a recursive 
> combination of dict/list/string/scalar/CFObject) and returns its CF 
> equivalent, and each CFObject has a toPython() method that does the 
> reverse. And due to the way Carbon.CF works you hardly ever have to 
> call toCF(), usually if a conversion from a Python object is needed it 
> is done automatically.
Given the equivalence of lots of NS<X> classes with CF<X> types the 
toCF() function could easily be used to implement a toObjC() function.

>
> And in PyObjC we have support for using NS objects in a way that is 
> natural to Python, i.e. you can say obj[12] here. But when I last 
> looked PyObjC didn't handle all object types, and handled some in a 
> slightly funny way (strings, scalars). Note that "slightly funny" is 
> meant derogatory here, doing automatic conversion for these types is 
> often a good idea, but may come back to haunt us now that unicode is 
> more important, and now that a Python program may have obtained a 
> CFString object from another source.

The funny conversions grew up since the last time you looked at them: 
Unicode is handled correctly (I added this when I wanted to process 
keyboard events for function keys, those are unicode characters without 
an ASCII equivalent).

Ronald