Swift2Python 0.9.0

Swift2Python 0.9.0

Swift2Python 0.9.0 is the first public field-test release. The core API is in place for calling Python from Swift, converting values between Swift and Python, working with Python containers, and using synchronous isolated-context APIs when performance or ergonomics matter.

This release is more-or-less like release 1.0, but Swift2Python doesn't have any users so I made it 0.9.0 until it's actually proven to work.

Swift2Python is supposed to "just work". No worrying about the GIL. No worrying about API or Python versions. Concurrency is taken care of. No worrying about object lifetimes. No deadlocks or crashes. Just use Python for things.

Highlights

• Async PythonObject API for Python imports, calls, attributes, operators, containers, iteration, and conversion.
• withIsolatedContext and SafePythonObject for synchronous Python work inside an interpreter-isolated closure.
• Runtime configuration through PythonRuntime, including environment-based Python library and PYTHONPATH setup.
• Swift-to-Python and Python-to-Swift conversions for common primitive and container values.
• Tuple, list, dictionary, set, bytes, callable, attribute, item, arithmetic, bitwise, comparison, and logical operation support.
• Structured PythonError handling with preserved Python exception information and traceback text.
• Improved object lifecycle and reference-count management for PythonObject and SafePythonObject.
• escapeFromIsolation(forSafeObj:) for intentionally returning a safe Python value from an isolated context as an owning PythonObject.
• Python-style negative tuple indexing through tupleItem(at:).

Requirements

• Swift 6 language mode
• Swift tools version 6.0 or newer
• macOS 15 or newer, or iOS 16 or newer
• A compatible CPython runtime available to the process

Swift2Python is currently developed and tested primarily on macOS with GIL-enabled CPython. Linux, iOS deployment scenarios, free-threaded Python, and older Python versions need more field testing.

Notes

This is a 0.9.0 release, not a 1.0 stability promise. Feedback is especially useful around:

• Python runtime discovery and configuration
• Long-running interpreter use
• Reference counting and object lifetime behavior
• withIsolatedContext and SafePythonObject ergonomics
• Third-party Python package imports
• Cross-platform behavior

(Also I've never made a software release before so it's entirely possible something is messed up in an obvious way that "everyone knows" about. But I don't know -- because you don't know until you know.)