Registry / http-networking / pyobjc-framework-threadnetwork

pyobjc-framework-threadnetwork

library12.2pypypiunverified

pyobjc-framework-threadnetwork provides Python wrappers for the macOS ThreadNetwork framework, enabling Python scripts to interact with Apple's Thread networking APIs. As part of the larger PyObjC project, it acts as a bridge between Python and Objective-C, allowing full-featured Cocoa applications to be written in pure Python. The library is actively maintained, with version 12.1 released on 2025-11-14, following a regular release cadence.

http-networking serialization web-framework

pip install pyobjc-framework-threadnetwork

github ↗package ↗docs ↗

INSTALL

IMPORT

SIG · PYOBJC-FRAMEWORK-T

pyobjc-framework-threadnetwork

http-networkingpythonv12.2

Install

—

Import

—

Disk

—

Pass rate

0/ 10

Env Coverage0 / 10

glibc

3.9–3.13

musl

3.9–3.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.10–3.920 runs

build_error

glibc

py 3.10–3.920 runs

build_error

Code

Verified usage

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

ThreadNetwork

✓ import ThreadNetwork

Framework bindings are accessed via a package with the same name as the macOS framework itself.

This quickstart demonstrates the basic import of the `ThreadNetwork` framework and a minimal interaction with a core Objective-C class (`NSObject` from `Foundation`) to confirm the PyObjC bridge is working. Direct, meaningful interaction with the `ThreadNetwork` framework typically requires specific macOS environments or hardware, which is beyond a general quickstart.

import ThreadNetwork import Foundation # The ThreadNetwork framework often requires specific macOS APIs and hardware # to perform meaningful operations. This quickstart demonstrates importing # the framework and a basic PyObjC interaction with NSObject from Foundation # to illustrate the bridge's functionality. # Instantiate a generic Objective-C NSObject using PyObjC's Pythonic syntax (since PyObjC 10.4) # For older PyObjC versions or explicit Objective-C style: # obj = Foundation.NSObject.alloc().init() obj = Foundation.NSObject.new() print(f"Successfully imported ThreadNetwork and created an NSObject: {obj.description()}") print(f"Is obj an instance of NSObject? {isinstance(obj, Foundation.NSObject)}")

Debug

Known issues

breakingPyObjC releases frequently drop support for older Python versions. Version 12.0 dropped Python 3.9, and version 11.0 dropped Python 3.8. Users should ensure their Python environment is compatible with the installed PyObjC version.

fix

Upgrade to a supported Python version (3.10+ for PyObjC 12.1) or pin to an older PyObjC version that supports your Python interpreter.

affects: 11.0, 12.0 and later

breakingPyObjC 11.1 introduced a significant change in how Automatic Reference Counting (ARC) is handled for Objective-C initializer methods. The core bridge now correctly models that methods in the 'init' family steal a reference to self and return a new one, which might alter behavior for code relying on the prior 'partially initialized' proxy state for `[NSObject alloc]` results.

fix

Review code interacting with `alloc().init_...()` patterns, especially custom Objective-C classes or complex instantiation flows, to ensure compatibility with clang's ARC rules. PyObjC 10.4 introduced a more Pythonic `Class(...)` instantiation which is generally recommended.

affects: 11.1 and later

gotchaThere was a temporary breakage in PyObjC 10.3 regarding the interaction between Python's `__init__` and `__new__` methods when subclassing Objective-C classes. While `__init__` usage was re-introduced in 10.3.1 for classes with user-implemented `__new__`, code relying on PyObjC's default `__new__` still cannot use `__init__` in specific scenarios. This reflects the inherent complexity of integrating Python's object model with Objective-C's two-phase instantiation.

fix

When subclassing Objective-C classes, explicitly define Objective-C style `init` methods in your Python class. If overriding `__new__`, ensure it correctly handles the PyObjC object lifecycle. Prefer the Pythonic `Class(...)` instantiation where possible, as it abstracts away some of these complexities.

affects: 10.3, partially fixed in 10.3.1

gotchaBuilding PyObjC from source, or using features dependent on specific macOS SDKs, requires a compatible Xcode or Command Line Tools installation. Using an older SDK than intended by the PyObjC version can lead to build errors.

fix

Ensure your Xcode or Command Line Tools are up-to-date for your macOS version, or that you have the SDK required by the PyObjC version you are trying to use. `pip install pyobjc` typically installs pre-built wheels, avoiding this for most users.

affects: All versions when building from source or using specific SDK-dependent features

gotchaWhile PyObjC 11.0 introduced experimental support for PEP 703 (free-threading) in Python 3.13, earlier versions like PyObjC 10.3 did not support it. Developers should be mindful of this when targeting free-threaded Python environments.

fix

Consult the PyObjC documentation for the specific version you are using regarding free-threading compatibility. Avoid using PyObjC with experimental free-threading features if not explicitly supported or if stability is critical.

affects: Versions prior to 11.0 (no support), 11.0+ (experimental support)

Upgrade

Version history

12.2latest on PyPI · released May 30, 2026

Audit

Dependencies

pyobjc-corerequiredProvides the core bridge functionality between Python and Objective-C, upon which all framework wrappers depend.

Agent activity

4 hits · last 30 days

node

Resources

githubhttps://github.com/ronaldoussoren/pyobjc ↗

packagehttps://pypi.org/project/pyobjc-framework-threadnetwork/ ↗

docshttps://pyobjc.readthedocs.io/en/latest/ ↗