PyObjC CryptoTokenKit Framework

Warnings

• breaking PyObjC 12.0 dropped support for Python 3.9. Users on Python 3.9 must use an older version of PyObjC.
  Fix: Upgrade to Python 3.10 or later, or pin `pyobjc-framework-cryptotokenkit` to `<12.0`.
• breaking PyObjC 11.0 dropped support for Python 3.8. Users on Python 3.8 must use an older version of PyObjC.
  Fix: Upgrade to Python 3.9 or later, or pin `pyobjc-framework-cryptotokenkit` to `<11.0`.
• gotcha PyObjC 11.1 aligned its behavior for Objective-C 'init' family methods with `clang`'s automatic reference counting documentation. This means that methods in the 'init' family now correctly steal a reference to `self` and return a new reference, which may affect custom initializers written in Python.
  Fix: Review Python implementations of Objective-C 'init' methods to ensure correct reference counting, especially if manual memory management was previously assumed or if issues with object lifecycle occur.
• gotcha The interaction between Python's `__init__` and `__new__` methods changed in PyObjC 10.3, where `__init__` could not be used with PyObjC-provided `__new__`. A partial reintroduction in v10.3.1 allowed `__init__` when a user implements `__new__`, but not when relying on PyObjC's `__new__`.
  Fix: If encountering issues with object initialization, especially when subclassing Objective-C classes in Python and using custom `__new__` or `__init__`, consult the 10.3.1 release notes and adapt your object creation pattern.
• gotcha While PyObjC 11.0 and 10.3 include experimental support for free-threading (PEP 703) introduced in Python 3.13, it does not fully support this feature. Users should be aware of potential limitations or issues when running PyObjC with a free-threaded Python interpreter.
  Fix: Avoid using PyObjC in contexts that heavily rely on Python's experimental free-threading, or thoroughly test your application in such environments and report any issues.
• deprecated `objc.ObjCLazyModule` is deprecated. The lazy loading mechanism now defaults to using module-level `__dir__` and `__getattr__`. This changes how attributes are accessed and ensures private symbols from dependencies are no longer implicitly imported.
  Fix: Update code that relies on `objc.ObjCLazyModule` or expects `objc` as an attribute of framework binding packages. Access symbols directly from the framework package (e.g., `Foundation.NSString` instead of `Foundation.objc.NSString`).

Install

• pip install pyobjc-framework-cryptotokenkit Install package

Imports

• CryptoTokenKit

  import CryptoTokenKit

  Framework bindings are accessed directly by importing the framework name as a Python package.
• TKTokenDriver

  from CryptoTokenKit import TKTokenDriver

  Classes within the framework are accessed as attributes of the imported framework module.

Quickstart

This quickstart demonstrates how to import the `CryptoTokenKit` framework and access one of its core classes, `TKTokenDriver`. While many classes in `CryptoTokenKit` are meant to be used within macOS app extensions for cryptographic token management, this snippet validates that the PyObjC bindings are correctly installed and accessible.

import CryptoTokenKit

# Accessing a class from the CryptoTokenKit framework
# Note: Instantiating many CryptoTokenKit classes directly in a script
# without being a proper macOS token extension might not be meaningful.
# This example primarily demonstrates successful import and class access.

token_driver_class = CryptoTokenKit.TKTokenDriver

print(f"Successfully imported CryptoTokenKit.")
print(f"TKTokenDriver is a: {type(token_driver_class)}")
print(f"Name of the TKTokenDriver class: {token_driver_class.__name__}")

# Example of attempting to access a class method (if available)
# (This specific call might not be functional without a running token service)
# if hasattr(token_driver_class, 'driverExtensionPointForIdentifier_'):
#     print(f"TKTokenDriver has driverExtensionPointForIdentifier_ method.")