Pyobjc

Latest version: v11.0

Safety actively analyzes 700916 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 18

11.0

-----------------------------------------------------------

The major change in this release is experimental support for free-threading
(`PEP 703 <https://peps.python.org/pep-0703/>`_) which was introduced
as an experimental feature in Python 3.13.

This required fairly significant changes in the core of PyObjC to change
C Python API use and PyObjC internal APIs (mostly related to the use of
borrowed references).

* Dropped support for Python 3.8. PyObjC 11 supports Python 3.9 and later.

* Updated metadata for the macOS 15.2 SDK, including bindings
for the following frameworks:

- MediaExtension
- DeviceDiscoveryExtension

* :issue:`249`: Added minimal bindings to the Carbon framework.

At this time only some functions and constants related to hotkeys
are available. Please file an issue if you have a usecase for other APIs.

* :issue:`615`: Struct wrappers now support a number of functions from
:mod:`copy`: :func:`copy.replace` (new in Python 3.13), :func:`copy.copy`
and :func:`copy.deepcopy`.

* The ``__pyobjc_copy__`` method has been removed from struct wrappers. This
was never a public API. Use :func:`copy.deepcopy` instead.

* :meth:`objc.FSRef.from_path`` now supports ``os.PathLike`` values as its
arguments (as well as strings).

* :issue:`608`: Experimental support for the free-threading mode
introduced in Python 3.13.

The core bridge and framework bindings claim compatibility with free-threading
as introduced as an experimental feature in Python 3.13.

The support in PyObjC is also an experimental feature: I've reviewed
code for free-threading issues and adjusted it where needed, but the
code has seen only light testing w.r.t. concurrency.

Some functionality that's explicitly not thread-safe:

- Defining an Objective-C class with the same name in multiple threads concurrently.

- Splitting calls to ``alloc`` and ``init`` and calling ``init`` multiple
times concurrently. E.g.:

.. sourcecode:: python

import threading
from Cocoa import NSObject

v = NSObject.alloc()

t_list = []
for _ in range(2):
t = threading.Thread(target=lambda: v.init())
t_list.append(t)
t.start()

for t in t_list:
t.join()

* The internal mapping from Python values to their active Objective-C
proxy value now uses weak references. This should not affect user code,
other than being a bit more efficient.

* The internal interfaces for updating this mapping, and the reverse mapping
from Objective-C values to their active Python proxy was changed to remove
a small race condition. This was required for free threading support, but
could in theory also bit hit when using the GIL.

* The data structure for mapping Python values to their Objective-C proxy
has been rewritten to support free threading. This also simplifies the
code, and should be small performance improvement for the regular build
of Python.

* The :exc:`TypeError` raised when passing a non-sequence value to
some APIs implemented in C now has a ``__cause__`` with more detailed
information.

This is a side effect of dropping the use of ``PySequence_Fast`` in the
implementation of PyObjC.

* Removed ``objc.options._nscoding_version``, a private option that is no
longer used.

* Changing the ``__block_signature__`` of a block value when the current
value of the signature is not ``None`` is no longer possible.

Please file an issue if you have a use case for changing the signature
of a block.

* Fix compatibility with Python 3.14 (alpha 3)

* Removed private function ``objc._sizeOfType`` because its unused.

* Fix memory leak when using Python callables as blocks.

The memory leak also resulted in leaking a reference to the callable
(and hence anything kept alive by that reference).

* The generic ``__new__`` implementation now works as intended when
registering methods that other than ``init...`` methods.

* Dropped '%n' support in handling printf-format strings for variadic
functions and methods.

Two reasons for that: 1) supporting this properly should return the
value writing to the %n location (requiring significant changes) and
2) Apple's libraries require using static strings for '%n' to work (at
least on some platforms and versions of the OS)

* :issue:`633`: Fix manual bindings for ``AVAudioPCMBuffer`` methods for
getting channel data (``floatChannelData``, ``int16ChannelData`` and
``int32ChannelData``)

* :issue:`632`: fix broken bindings for ``CGWindowListCreateImageFromArray``.

* The private ``__is_magic`` attribute on :class:`objc.objc_object` has
been renamed to ``__pyobjc_magic_coookie__``.

* Various fixes to edge case behaviour that were found while improving
test coverage.

10.3.2

--------------

* Fix a number of test failures on the first macOS 15 beta. These are
all documentation and test updates.

* :issue:`593`: PyObjCTools.AppHelper.runConsoleEventLoop no longer
exits the process on macOS 14 or later when stopping the event loop.

* :issue:`613`: Actually expose protocols ``KHTTPCookieStoreObserver``,
``WKURLSchemeTask``, and ``WKURLSchemeHandler`` in the WebKit bindings.

* :issue:`621`: Drop dependency on ``setuptools.command.test`` which is deprecated
and will be removed by the end of the year.

* :issue:`627`: Fix build issue when deployment target is 15.0 or later.

* :issue:`623`: Don't lowercase the first character of the first keyword
argument for ``__new__`` when the segment only contains upper case
characters.

Before this change ``initWithURL:`` mapped to an ``uRL`` keyword argument,
with this fix the keyword argument is named ``URL``.

Fix by user rndblnch on github

* :issue:`625`: Fix crash for calling ``NSIndexSet.alloc().initWithIndex_(0)``

This "fix" is a workaround for what appears to be a bug in Foundation.

* The proxy objects created when passing a Python callable to an Objective-C
method/function expecting a block value were never released due to an error
in the cleanup code in PyObjC.

* Variadic methods and functions where the one of the arguments contains a
count of the number of variadic values now work as intended (so far this
feature hasn't been necessary in binding Apple frameworks, so shouldn't
affect existing code)

* Add support for 'long double' in function/method interfaces, including support
for '%Ld' in printf-style varargs handling.

Note that this primarily affects x86_64, on arm64 systems 'long double'
is effectively an alias for 'double'.

10.3.1

--------------

* :issue:`610`: Ensure ``__init__`` can be used when user implements ``__new__``.

Version 10.3 dropped support for calling ``__init__``, but that breaks
a number of popular projects. Reintroduce the ability to use ``__init__``
when a class or one of its super classes contains a user implemenentation
of ``__new__``.

Code relying on the ``__new__`` provided by PyObjC still cannot use
``__init__`` for the reason explained in the 10.3 release notes.

* :issue:`619`: Fix race condition in creating Python proxyies for
Objective-C classes.

10.3

------------

* The release contains binary wheels for Python 3.13

PyObjC does at this time not support the experimental free threading
support in Python 3.13.

* :issue:`569`: Removed the workaround for a bug in Xcode 15.0

The workaround is no longer necessary, and caused problems when
building with the Command Line Tools development tools from Apple.

* Updated SDK bindings for macOS 14.5

* A minor change in the (currently private) tooling I use for
collecting the raw metadata resulted in minor fixes to the framework
bindings, in particular for metadata for a number of block and function
typed arguments and return values.

* :issue:`275`: It is now possible to create instances of Objective-C
classes by calling the class, e.g. ``NSObject()`` instead of
``NSObject.alloc().init()``.

The implementation of ``__new__`` forwards calls to the underlying
``SomeClass.alloc().init...()`` pattern. In particular, all public init
methods are translated into sets of keyword arguments:

- Remove `init` or `initWith` from the start of the selector name
- Lowercase the first character of what's left over
- The strings before colons are acceptable keywords, in that order

For example, given a selector ``initWithX:y:`` the ``__new__`` method
will accept ``x, y`` as keyword arguments, in that order.

Framework bindings have been updated with additional metadata to support
this pattern, and the sets of keyword arguments are automatically calculated
for subclasses in written in Python.

The limitation on the order of keyword arguments may be lifted in a future
version, it is currently present to keep the code closer to the Objective-C
spelling which should make it easier to look up documentation on Apple's
website.

* For some Objective-C classes some of the `init` and `new` methods are not
available even if they are available in super classes. Those methods are
marked with ``NS_UNAVAILABLE`` in Apple's headers.

As of this version these methods are also not available in Python code,
trying to call them will result in an exception.

To make methods unavailable in Python classes set these methods to ``None``,
e.g.:

.. sourcecode:: python

class MyObject(NSObject):
init = None NS_UNAVAILABLE

* Added :func:`objc.registerUnavailableMethod`,
:func:`objc.registerNewKeywordsFromSelector` and
:func:`objc.registerNewKeywords` to support the generic ``__new__``
in framework bindings.

A limitation for ``registerUnavailableMethod`` is that it is currently
not supported to reintroduce the method in a subclass, primarily because
that functionality is not needed for framework bindings.

* Instantiating an Objective-C class by calling the class (e.g. invoking
``__new__``) will not call ``__init__`` even if one is defined.

The implementation of a subclass of ``NSObject`` should always follow
the Objective-C convention for initializing using one or more
methods with a name starting with ``init``.

This can affect code that manually defines a ``__new__`` method for
an Objective-C class, in previous versions that was the only way
to create instances in a Pythontic way.

The primairy reason for this change is that the new default ``__new__``
implementation resulted in calling ``__init__`` for some code paths and
not others due to the python semantics for creating instances, e.g.:

.. sourcecode:: python3

class MyDocument(NSDocument):
def __init__(self, *args, **kwds): pass

document = MyDocument() __init__ gets called
document, error = MyDocument(type="mytype", error=None). __init__ does not get called

In the last statement ``__init__`` does not get called because
``__new__`` does not return an instance of ``MyDocument``.

* ``NSArray``, ``NSMutableArray``, ``NSSet`` and ``NSMutableSet`` accepted
a ``sequence`` keyword argument in previous versions. This is no longer supported.

It is still supported to create instances using a positional argument
for a sequence, e.g. ``NSArray([1, 2, 3])``.

* ``NSData``, ``NSMutableData``, ``NSDecimal``, ``NSString`` and ``NSMutableString``
accepted a ``value`` keyword argument in previous versions. This is no longer supported.

It is still supported to create instances using a positional argument,
e.g. ``NSData(b"hello")``.

* ``NSDictionary`` and ``NSMutableDictionary`` do *not* support the
generic new interface because this conflicts with having a similar
interface to ``dict`` for creating instances.

That is, ``NSDictionary(a=4, b=5)`` is the same as ``NSDictionary({"a":4, "b":5})``,
and not like ``NSDictionary.alloc().initWithA_b_(4, 5)``.

10.2.1

--------------

* Fix possible memory corruption in the implementation of ``forwardInvocation:``
for Python classes.

* Fix build error when building with a python configured with ``--with-pydebug``.

* Don't override ``tp_dealloc`` slot in :class:`objc.super` but use the one
inherited from :class:`super`. This makes sure construction and deallocation
are consistent with each other (found while testing with ``--with-pydebug``).

* Fix deprecation warning while compiling ``pyobjc-framework-Quartz``.

10.2

------------

* Fix a number of warnings found by adding ``-Wpendantic`` to the CFLAGS for
pyobjc-core

* Fix undefined behaviour warnings:

- Suppress the undefined behaviour warning about out of range values in
double to (unsigned) long long in the ``OC_PythonNumber`` implementation
as these are unavoidable when matching ``NSNumber`` behaviour.

- Switch to using ``memcpy`` instead of direct assignment in converting
plain C values to/from Python because "packed" structs might result
in accessing values through unaligned pointers.

* Updated bindings for the macOS 14.4 SDK (Xcode 15.3)

* Added bindings for the "BrowserEngineKit" framework on macOS 14.4 or later.

* Add :func:`obj.registerPathType` to register a Python type as a path like
type with PyObjC. By default only :class:`pathlib.Path` is registered as such.

A minor backward compatibility issue is that instances of the registered types
will be written to ``NSArchive`` and ``NSKeyArchive`` archives as instances
of ``NSURL`` and won't roundtrip back to the original Python type. This might
change in future versions of PyObjC, at least for :class:`pathlib.Path`.

* :issue:`589`: Instances of :class:`pathlib.Path` (and other types registered with
`objc.registerPathType`) are bridged into Objective-C as instances of ``NSURL``.

This means that these types can be used as values passed to APIs expecting
a filesystem URL, e.g.:

.. sourcecode:: python

path = pathlib.Path("/Applications/Numbers.app")
bundle = NSBundle.bundleWithURL_(path)

* Fix some warnings in pyobjc-core when testing with Python 3.13a4.

* Add support for ``NSBezierPathElementQuadraticCurveTo`` in ``NSBezierPath.elementAtIndex_associatedPoints_``.

* :issue:`595`: Fix compilation error in ``pyobjc-framework-Cocoa`` with a recent
deployment target.

Page 1 of 18

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.