Registry / pyobjc-framework-compositorservices

pyobjc-framework-compositorservices

JSON →
library12.2pypypiunverified

This library provides Python bindings for the macOS CompositorServices framework, enabling interaction with its Objective-C APIs. CompositorServices is a highly specialized framework used for building custom rendering pipelines for displays connected to Apple silicon. This specific binding is part of the larger PyObjC project, currently at version 12.1, which maintains a regular release cadence with updates corresponding to macOS SDK changes and Python version support.

pip install pyobjc-framework-compositorservices
INSTALL
IMPORT
SIG · PYOBJC-FRAMEWORK-C
P
pyobjc-framework-compositorservices
pythonv12.2
Install
Import
Disk
Pass rate
0/ 10
Env Coverage0 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v? · pip install
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.920 runs
build_error
glibc
py 3.103.920 runs
build_error
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

CSDisplay
from CompositorServices import CSDisplay
Classes within the CompositorServices framework are typically prefixed with 'CS'.

Due to the highly specialized nature of the CompositorServices framework, a simple 'Hello World' directly using its APIs is not practical. This quickstart demonstrates basic PyObjC object creation and method calling using the general Foundation framework. To use CompositorServices, you would import its specific classes (e.g., `CSDisplayManager`) and interact with them according to Apple's CompositorServices documentation for macOS.

import objc from Foundation import NSObject, NSBundle # CompositorServices is a highly specialized framework. # A simple 'Hello World' for it is not practical without # deep knowledge of macOS graphics programming. # This example demonstrates basic PyObjC class instantiation. class MyPyObjCClass(NSObject): def init(self): self = super().init() if self is None: return None print("MyPyObjCClass instance initialized!") return self @objc.python_method def say_hello(self): print("Hello from PyObjC!") if __name__ == "__main__": # Instantiate a basic PyObjC object obj = MyPyObjCClass.alloc().init() obj.say_hello() # For CompositorServices, you would import and use specific classes like: # from CompositorServices import CSDisplayManager # manager = CSDisplayManager.sharedManager() # ... and interact with its methods according to Apple's documentation.
Debug
Known issues
breakingPyObjC 12.0 dropped support for Python 3.9. Ensure your environment uses Python 3.10 or later.
fix
Upgrade your Python interpreter to 3.10 or newer.
affects: 12.0 and later
breakingPyObjC 11.0 dropped support for Python 3.8. Users on older PyObjC versions should be aware of this if upgrading.
fix
Upgrade your Python interpreter to 3.9 or newer (for PyObjC 11.x) or 3.10+ (for PyObjC 12.x).
affects: 11.0 and later
gotchaThe CompositorServices framework and its bindings were newly introduced in PyObjC 12.0, corresponding to the macOS 26 SDK (likely macOS 15+). It will not be available in older PyObjC versions or on macOS versions that do not support CompositorServices.
fix
Ensure you are using PyObjC 12.0 or later and targeting a sufficiently new macOS SDK.
affects: All versions before 12.0
gotchaPyObjC 11.1 aligned initializer method behavior with Clang's Automatic Reference Counting (ARC) documentation. This means `init` family methods now correctly model stealing a reference to `self` and returning a new one. This might subtly alter memory management behavior compared to previous versions if custom `init` methods were relying on older PyObjC semantics.
fix
Review custom `init` implementations to ensure they correctly handle reference counting, especially when interacting with `alloc` and `super().init()`.
affects: 11.1 and later
gotchaChanges in PyObjC 10.3 and 10.3.1 affected the interaction between `__init__` and `__new__` for Python subclasses of Objective-C objects. While 10.3.1 partially restored support for `__init__` when a user implements `__new__`, code relying on PyObjC's default `__new__` still cannot use `__init__`.
fix
If implementing `__new__` in a Python subclass of an Objective-C object, ensure `__init__` is used cautiously. Consider initializing instance state within `__new__` or a dedicated setup method if you're not overriding `__new__`.
affects: 10.3, 10.3.1
gotchaExperimental free-threading (PEP 703) in Python 3.13 is an experimental feature and was introduced in PyObjC 11.0 with significant internal changes. PyObjC versions like 10.3 explicitly state they do not support this experimental feature, and caution should be exercised when using it with any PyObjC version.
fix
If working with Python 3.13 and free-threading, consult the latest PyObjC documentation for compatibility and known issues. For stability, consider sticking to standard CPython builds without free-threading.
affects: 10.3 to 11.0 (experimental), potential issues in later versions with free-threading Python
Upgrade
Version history
12.2latest on PyPI · released May 30, 2026
Audit
Dependencies
pyobjc-corerequiredThis is a framework binding that relies on the core PyObjC bridge for Objective-C interaction.
Agent activity
2 hits · last 30 days
node
2
Resources
pyobjc-framework-compositorservices — pip install pyobjc-framework-compositorservices · libregistry