Pyobjc

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

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

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

* Remove workaround for a linker problem in early versions of Xcode 15, which restores support for building with Xcode Command Line tools.

* The release contains wheels for the free-threaded build of Python 3.13.

Note that PyObjC does not support running without the GIL at this time.

* Fix for running test suite with recent versions of setuptools

Recent versions of setuptools broke the "test" command, the full command has been reimplemented as part of PyObjC.

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

* 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

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

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

* 569: Actually remove the workaround for Xcode 15.0

* 619: Fix race condition in creating proxy objects for Objective-C classes.

* 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.

* 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.

* 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.

* 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.:

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.

* ``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)``.

* 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`.

* 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.:

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_``.

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

* Upgrade framework bindings for the macOS 14.2 SDK

* 579: Make sure the ``install.py`` and ``develop.py`` scripts in the
repository work when run out of tree.

* 577: ``os.fspath(someURL)`` will not work with Cocoa URLs (NSURL, CFURLRef) that
refer to local filesystem paths. ``TypeError`` will be raised for other URLs.

This enables using regular Python filesystem APIs with URLs that refer to
local filesystem paths.

* 572: Fix compilation issue when building on macOS 13 or earlier

* Fix build error on ancient macOS versions where clang doesn't support
``-flto=thin``.

* Add a workaround for a crash in pyobjc-core when running the testsuite
on macOS 10.14.

* Fix some issues found while running the testsuite on macOS 10.9 to
macOS 13, instead of only testing on the latest macOS version. Most
issues found where problems in the testsuite itself, but not all.

Some of the changes skip tests on older macOS versions (10.12, 10.13
and 10.14) due to running into what appears to be crashing
platform bugs.

* 581: Fix dependencies between framework binding packages

* Fix build error with the current Python 3.13 alpha release (3.13a2).

* Update bindings for macOS 14

Symbols newly introduced in macOS 14 were added to the existing bindings,
and the following new bindings were introduced:

* Cinematic

* MediaExtension

* SensitiveContentAnalysis

* Symbols

* The "IMServicePlugIn" bindings are no longer available

The entire framework was deprecated in macOS 10.13 and removed in macOS 14.
The bindings can not be build using the latest SDK, and had (at best) limited
use.

* 542: PyObjC 10 requires Python 3.8 and no longer supports Python 3.7

* 547: Removed all ``MAC_OS_X_VERSION*`` constants from ``objc``.

These constants are needed in practice (switch to :func:`objc.available` to
check for platform availability), and caused unnecessary code churn.

* The value for ``objc.options.deprecation_warnings`` is now a string
instead of an integer.

* 555: Fix unintended incompatibility with pytest in PyObjCTools.TestSupport

* 295: The lazy loading machinery by default no longer uses
``objc.ObjCLazyModule``, but uses module level ``__dir__`` and
``__getattr__`` instead. The class :class:`objc.ObjCLazyModule` is still
available, but is deprecated

As a side effect of this ``objc`` is no longer an attribute of framework
binding packages (e.g ``Foundation.objc`` is no longer a valid attribute).

Another side effect of this is that all attributes added by the import system
are now correctly present in the packages for framework bindings.

And a final side effect is that private symbols (prefixed with underscore) are
no longer imported from dependencies of framework bindings (more closely matching
the ``from dependency import *`` behaviour that the lazy importer emulates.

* Add attribute ``__framework_identifier__`` to all framework bindings with the
identifier of the corresponding system framework.

* 295: Introduce :func:`objc.createFrameworkDirAndGetattr` to
create module level ``__dir__`` and ``__getattr__`` for use by
framework bindings.

* 561: Tests now validate the bundle identifier value used in framework bindings.

This resulted in a number of changes to framework bindings with incorrect
bundle identifier values. This shouldn't affect user code because the
bundle loader falls back on the framework path when the identifier cannot be found.

* 559: Avoid test failures in pyobjc-core when pyobjc-framework-Quartz is
not installed.

* A number of classes can no longer be subclasses in Python because they are marked as non-subclassable
in the macOS 14 SDK (either directly or as "subclassing is deprecated":
``CKAllowedSharingOptions``,
``CKAsset``,
``CKContainer``,
``CKDatabase``,
``CKDatabaseNotification``,
``CKDatabaseSubscription``,
``CKFetchRecordZoneChangesConfiguration``,
``CKNotification``,
``CKNotificationID``,
``CKNotificationInfo``,
``CKOperationConfiguration``,
``CKOperationGroup``,
``CKQuery``,
``CKQueryCursor``,
``CKQueryNotification``,
``CKQuerySubscription``,
``CKRecord``,
``CKRecordID``,
``CKRecordZone``,
``CKRecordZoneID``,
``CKRecordZoneNotification``,
``CKRecordZoneSubscription``,
``CKReference``,
``CKServerChangeToken``,
``CKShare``,
``CKShareMetadata``,
``CKShareParticipant``,
``CKSubscription``,
``CKSyncEngine``,
``CKSyncEngineAccountChangeEvent``,
``CKSyncEngineConfiguration``,
``CKSyncEngineDidFetchChangesEvent``,
``CKSyncEngineDidFetchRecordZoneChangesEvent``,
``CKSyncEngineDidSendChangesEvent``,
``CKSyncEngineEvent``,
``CKSyncEngineFailedRecordSave``,
``CKSyncEngineFailedZoneSave``,
``CKSyncEngineFetchChangesOptions``,
``CKSyncEngineFetchedDatabaseChangesEvent``,
``CKSyncEngineFetchedRecordDeletion``,
``CKSyncEngineFetchedRecordZoneChangesEvent``,
``CKSyncEngineFetchedZoneDeletion``,
``CKSyncEnginePendingDatabaseChange``,
``CKSyncEnginePendingRecordZoneChange``,
``CKSyncEnginePendingZoneDelete``,
``CKSyncEnginePendingZoneSave``,
``CKSyncEngineRecordZoneChangeBatch``,
``CKSyncEngineSendChangesContext``,
``CKSyncEngineSendChangesOptions``,
``CKSyncEngineSentDatabaseChangesEvent``,
``CKSyncEngineSentRecordZoneChangesEvent``,
``CKSyncEngineState``,
``CKSyncEngineStateSerialization``,
``CKSyncEngineStateUpdateEvent``,
``CKSyncEngineWillFetchChangesEvent``,
``CKSyncEngineWillFetchRecordZoneChangesEvent``,
``CKSyncEngineWillSendChangesEvent``,
``CKSystemSharingUIObserver``,
``CKUserIdentity``,
``CKUserIdentityLookupInfo``.

* The encoding of a number of basic types changes, in particular those
of CoreFoundation struct types and SIMD struct types. None of this
should affect user code.

* ``objc.getClassList`` now has an optional positional argument to
ignore classes with a name that aren't identifiers.

* Some of the functionality in CoreFoundation was rewritten in Swift
in macOS 14, with Swift subclasses of ``NSArray`` and ``NSDictionary``.
Those classes break an invariant of PyObjC: the superclass of the root
of the Swift class hierarchy changes when the class is instantiated
for the first time (from ``NSObject`` to the correct superclass).

PyObjC 10 contains a workaround for this by ignoring these classes
unless they are needed to create a proxy for an instance (FB12286520).

* Fix crash when the method signature retrieved from the Objective-C runtime
contains the class name for a method returning ``id``.

* Remove old 32-bit support in metadata override files.

* Restructure ``objc.simd``: The matrix types are now named ``simd_float3x3``
instead of ``matrix_float3x3``, with the older name as an alias (to match
older system headers).

* Fix crash when loading the libdispatch bindings on recent macOS versions
(at least macOS 13, possibly earlier)

* ``dispatch.dispatch_source_t`` is renamed to ``dispatch.dispatch_source_type_t``
to match the type name in C code.

* 569: Xcode 15 has a bug when using weak symbols and targeting older macOS
versions. Switch to the old linker when detecting Xcode 15.