Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
Brought to you by:
ronaldoussoren
From: Ronald O. <ous...@ci...> - 2002-10-17 20:29:50
|
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 |