An introduction to PyObjC describes the general method for translating Objective-C calls into Python calls, including the handling of pass-by-reference arguments and buffers.
This document describes where the PyObjC bindings for this framework are different from the general rule, such as mentioning APIs that are not supported or where the interface is different than expected.
Incorrect usage of CoreFoundation API’s will often cause crashes of the Python interpreter. This is caused by the way CoreFoundation is implemented and it is not possible work create nice Python exceptions when this happens. The same crashes also happen when for incorrect usage in C programs.
Container datastructures, such as CFArray and CFTree, are only supported when the contain only CFTypeRef values even when the actual C API supports arbitrary pointer values.
Toll-free bridging applies to Python as well, and is more convenient than in Objective-C because you don’t have to cast between a CoreFoundation type and an Objective-C class.
This type is only supported when the callbacks are kCFTypeArrayCallBacks, accessing other CFArray values from Python is not supported and will crash your interpreter.
Note that all CFArrayRef instances are instances of NSArray or NSMutableArray as well.
The callbacks argument must be kCFTypeArrayCallbacks.
The context argument for CFArrayApplyFunction, CFArrayBSearchValues and CFArraySortValues can be an arbitrary object (unlike the context or userdata argument in a lot of other API’s).
This type is only supported when the callbacks are kCFTypeBagCallBacks, accessing other CFBag values from Python is not supported.
These function don’t have a callBacks argument in Python and will always use the kCFTypeBagCallBacks value for that argument in C.
The context argument for CFBagApplyFunction can be an arbitrary Python object.
The CFBinaryHeap wrappers assume that values are instances of CoreFoundation types or Objective-C classes.
The callbacks argument is not present in Python and is automaticly set to a value that allows arbitrary objects that implement the compare: method.
The compareContext argument is also not present in Python.
This function crashes the interpreter, the reason for that is unclear.
CFDictionaryCreate, CFDictionaryCreateMutable: the callback arguments are must be kCFTypeDictionaryKeyCallBacks and kCFTypeDictionaryValueCallBacks.
instances contain objects (both as keys and as values)
CFDictionaryApplyFunction: the context argument can be an arbitrary Python object.
The context argument for CFFileDescriptorCreate is a python object, the CFFileDescriptorContext is automaticly added by the bridge.
The CFFileDescriptorGetContext results the python object that was used in CFFileDescriptorContext, not a CFFileDescriptorContext structure.
NOTE: This means it is unsafe to call CFFileDescriptorGetContext on objects that weren’t created in Python code.
The current bindings for the CFMachPort API are probably useless, as there doesn’t seem to be a proper binding of the low-level API’s.
The context argument for CFMachPortCreate and CFMachPortCreateWithPort is a python object, the CFMachPortContext is automaticly added by the bridge.
The CFMachPortGetContext results the python object that was used in CFMachPortContext, not a CFMachPortContext structure.
This means it is unsafe to call CFMachPortContext on objects that weren’t created in Python code.
Note that Python numbers are automaticly translated to/from Objective-C numbers (NSNumber, which toll-free bridged to CFNumber). This means the CFNumber functions should almost never be necessary.
That said, all CFNumber API’s do actually work.
Both function require a manual wrapper to support, implementations are welcome.
The CFPlugin API’s are not supported at the moment. Likewise for the COM interface support in CoreFoundation.
The ‘context’ argument for CFRunLoopSourceCreate should be a tuple. The first element of the tuple is 0, the other elements are: a schedule callback, a cancel callback, a perform callback and an info object. The callbacks may be None.
Version 1 of the context object is not yet supported.
The CFRunLoopSourceGetContext returns this tuple, and will raise an exception when the context was not set from Python (that is, when asking for the context of a runloop source that was created in C code).
The context argument of CFRunLoopTimerCreate can be an arbitrary python object. This object is returned by CFRunLoopTimerGetContext.
The context argument of CFRunLoopObserverCreate can be an arbitrary python object. This object is returned by CFRunLoopObserverGetContext.
The socket context is an arbitrary object, not a callback structure. This has several effects: