Python.CodeCompared.To/Swift

Swift files run top to bottom with no entry-point function, no class wrapper and no imports for the basics — a Swift script and a Python script have the same shape. Semicolons are optional and nobody writes them. The one thing to know early is that this is a compiled language: what looks like a script is compiled before it runs, and every example on this page had to satisfy a type checker before it printed anything.

The interpolation can hold any expression, exactly as an f-string can, and it calls the value's description the way Python calls __str__. print also takes several arguments and joins them with a space, matching Python precisely, including the separator: and terminator: parameters that correspond to sep= and end=. Number formatting is the one place Swift is more awkward: f"{price:.2f}" becomes String(format: "%.2f", price).

swift script.swift compiles the file and then runs it, so the feedback loop is slower than Python's and gets much slower on a real app, where a clean Xcode build of a mid-sized project takes minutes. The REPL is genuinely good and is worth using for exploration, which is unusual among compiled languages. The compile step is what buys the guarantees on the rest of this page, and whether that trade is worth it is the argument the whole language is having.

In Python every name is a reference to an object, so second = first makes a second name for one thing and mutating through either is visible through both. A Swift struct is a value: assigning it, passing it to a function, or putting it in an array copies it, so the two variables cannot interfere. There is no aliasing to reason about, no defensive copy.deepcopy, and no question about whether a callee will mutate what you handed it. The copy is optimized away until something is actually written, so this costs nothing in the common case.

A class in Swift behaves the way every Python object behaves: it is a reference, it is shared, and a function that receives one can change what the caller sees. A struct cannot, which is why addApple has to return a new value for the struct version. Swift's guidance is to reach for struct first and use class when you need identity, inheritance, or deliberate shared mutable state — the opposite default from Python, where there is only the one option. Notice also that a let struct is deeply immutable: you cannot call a mutating method on it or change any of its properties.

Swift evaluates a default expression on every call rather than once at declaration, and the array is a value type that would be copied on assignment even if it did not. Note the second consequence, visible in the body: the parameter into is a let constant — Swift parameters are immutable — so mutating it requires an explicit local copy. That looks like extra work and is really the compiler making the copy visible where Python leaves it invisible and shared.

This is where value semantics pay off most in day-to-day code. A function can take an array, and the caller knows it will come back unchanged; a property can be handed out without wrapping it in list(...); and there is no equivalent of the Python surprise where two dictionaries turn out to be one. The implementation is copy-on-write, so passing a million-element array is still a pointer copy until somebody writes to it. If you genuinely want shared mutable state, you reach for a class and it is visible in the declaration.

A computed property is one with a body and no storage, which is @property; a set block gives it the setter half. The additions are willSet and didSet, which fire around a change to an ordinary stored property, so you can observe a plain field without converting it into a computed one and inventing a backing name. Python's equivalent requires the underscore-shadow dance in the left column, and every existing caller keeps working in both — which is the refactoring safety that made @property worth having in the first place.

String? is shorthand for Optional<String>, an enum with a .some(value) case and a .none case — so the absence is a wrapper around the value rather than a special value that can stand in for anything. That is the whole idea: because it is a different type, every place where absence is possible is visible in the signature, and every use of it has to say what happens when it is empty. It converts a run-time AttributeError into a compile error, which is the trade the rest of this section describes.

if let opens a block in which the unwrapped value exists; guard let binds it for the rest of the enclosing scope and requires its else branch to leave — return, throw, or break. That inversion is the point: a function written with guard handles every absent case at the top and then reads as straight-line code, which is the shape Python developers hand-roll with early returns. Swift also allows if let name with no = name, shadowing the name with its unwrapped self, which is what most modern Swift looks like.

?. short-circuits the whole chain to nil rather than crashing; ?? supplies a default and is the closest thing to value or default, except that it fires only on nil and not on empty strings or zero. ! is the force unwrap: it asserts the value is present and crashes the program if it is not, which is deliberately unpleasant to look at. Reviewers treat a ! as something to justify; the common exception is a value the compiler cannot know is present, such as an @IBOutlet wired up in a storyboard.

let is a constant binding and is the default a Swift programmer reaches for; the compiler warns when a var is never mutated. Inference is thorough enough that annotations appear mainly on function signatures, on stored properties, and where you want a type other than the obvious one — let price: Double = 20 above, since 20 alone would infer Int. There is no implicit numeric conversion at all: adding an Int to a Double does not compile, which is stricter than Python and catches a real class of unit mistakes.

An Int is 64 bits on every platform Swift supports, and overflow does not wrap silently the way it does in C, Java, Kotlin and Go — it traps and crashes the program. That is a deliberate decision that a wrong answer is worse than a stopped process, and the &+ family and the ...ReportingOverflow methods exist for when you want to handle it yourself. Division follows the C convention, so 7 / 2 is 3 and matches Python's // rather than its /; and because there are no implicit conversions, mixing an Int and a Double requires writing Double(...) explicitly.

A named tuple member is addressed as result.quotient rather than result.0, so a two-value return needs neither a struct nor a comment explaining the order. Destructuring works too: let (quotient, remainder) = divide(17, by: 5). typealias is a compile-time name for an existing type, exactly like Python's type alias, and creates no new type — so it documents intent without preventing you from passing the wrong thing. When you want a distinct type, you declare a struct.

A Swift Character is an extended grapheme cluster — everything a reader would call one character, however many code points went into it — so a regional-indicator flag counts as 1 and a four-person family emoji counts as 1. Python counts Unicode code points, so the same strings come back as 2 and 5. Swift's answer is the one a user would give, and the price is that a String cannot be indexed by an integer: there is no text[3], because the third character is not at a known offset. You use String.Index, or Array(text) when you genuinely want random access.

Swift's naming guidelines say that a method returning a new value reads as a noun phrase (uppercased(), trimmingCharacters, replacingOccurrences) while one that mutates in place reads as an imperative verb (uppercase(), sort()). Once you notice the rule, the name tells you whether the original changed — information Python leaves you to remember per method. split returns Substring values, which share storage with the original and are converted with String(...) when you need to keep them.

A Substring shares storage with the string it came from, so taking a prefix copies nothing — but it also keeps the whole original alive for as long as it exists, which is a memory leak waiting to happen if you store one. The type system makes that visible: a function taking a String will not accept a Substring, so you write String(middle) and the copy happens where you can see it. Python's slices always copy, which is simpler and occasionally much slower on large strings.

That homogeneity is why person above stores the age as a string: ["name": "Ada", "age": 36] has no single value type, and a mixed dictionary is what a struct is for. The other thing to notice is the ?? on every subscript: reading a missing key gives back an optional rather than raising a KeyError, so Swift's subscript behaves like dict.get() and there is no bracket form that crashes. Arrays are the reverse — an out-of-range index traps — because a missing index is a programming error while a missing key usually is not.

$0 is the implicit name for a closure's first argument ($1 for the second), which is why so much Swift reads as { $0.name }. The library is rich enough that most comprehensions have a shorter equivalent than a filter plus map: compactMap maps and drops nils in one step, first(where:) replaces a loop with a break, and Dictionary(grouping:by:) is defaultdict(list). For laziness — the generator-expression behavior — insert .lazy before the chain.

The difference worth knowing is ordering. Python dictionaries have preserved insertion order since 3.7 and it is guaranteed by the language; a Swift Dictionary is a hash table with no defined order at all, and its order can differ between runs of the same program. Any Swift code whose output depends on dictionary order is a bug waiting to be found, which is why the example sorts. When order matters, you keep an array of keys or use an ordered-dictionary type from the Swift Collections package.

Dictionary(grouping:by:) is defaultdict(list) plus the loop, in one call with the types worked out. The subscript with a default: is the counting idiom: counts[key, default: 0] += 1 reads and writes through one lookup and needs no defaultdict, so an ordinary dictionary does the job and there is no risk of accidentally inserting a key just by reading it — the classic defaultdict surprise. merging(_:uniquingKeysWith:) is the third one, replacing {**a, **b} with an explicit rule for collisions.

Both bind parts of the value, both take a guard clause (where rather than if), and both match on type. The difference is that Swift's switch must be exhaustive: leaving out a case that the compiler cannot prove is impossible is a compile error, not a silently missing branch. Over an enum that means adding a case breaks every switch that has not been updated, which is the strongest safety property in the language. There is also no fall-through — each case ends by itself — and ranges, tuples and optionals all have patterns of their own.

1...5 includes both ends; 1..<6 excludes the upper one and is the exact equivalent of range(1, 6). Having the choice in the syntax removes the off-by-one guessing that a single convention forces. A stepped or descending sequence needs stride(from:to:by:) rather than a third argument, which is more to type and reads more clearly at the call site. Ranges are values, work on any Comparable type, and can be used as switch patterns — case 90...100: in a grading switch is idiomatic.

if case .success(let value) = result reads oddly at first — the pattern is on the left of the = — and it is the same machinery a switch case uses, so it binds associated values the same way. guard case is the early-exit form and is how a function insists on one particular case before continuing. Python's match requires the full statement even for one case, so the equivalent is a match with a single arm and a case _: pass, which is why most Python code uses isinstance instead.

The label is mandatory at the call site unless the parameter is declared with _, which is the opposite of Python, where every argument may be passed positionally. That is why the function above is referred to as move(_:from:to:) — the labels are part of its identity, and two functions differing only in labels are two different functions. The payoff is that a Swift call reads as a sentence without the caller having to remember to write the names; the cost is that renaming a label breaks callers, so the labels are designed as carefully as the function name.

Since a Swift array is copied when passed, a function that wants to modify the caller's array must say so with inout, and the caller must agree by writing & at the call. The mutation is therefore visible in both places — you can tell from the call site alone that numbers may change, which is information a Python reader simply does not have. Under the hood it is copy-in, copy-out rather than a pointer, so there is no aliasing to reason about either.

Python has one function per name, and getting type-based dispatch requires functools.singledispatch and a registration for each type — which works at run time, on the first argument only. Swift resolves the overload at compile time using every argument and even the expected return type, so let count: Int = convert(text) can select a different function from let ratio: Double = convert(text). The cost is that a large overload set slows the type checker noticeably and produces error messages that are famously unhelpful when nothing matches.

That removes the recurring Python annoyance of a lambda outgrowing its single expression and having to become a named def. Everything else is shorthand: parameter names can be dropped in favor of $0 and $1, types can be inferred from context, and a single-expression body needs no return. Function types are written (Int) -> Int, the direct equivalent of Callable[[int], int], and are checked at compile time.

It is why numbers.sorted { … }, DispatchQueue.main.async { … } and every SwiftUI view body look like built-in constructs when they are ordinary function calls — and since Swift 5.3 several trailing closures can be chained with their labels, which is what makes animate { } completion: { } read the way it does. Python has no equivalent: a multi-statement callback must be a named function defined above the call, which is why the same designs show up there as decorators or context managers instead.

Swift needs no nonlocal — a closure that assigns to a captured var simply does, and the variable outlives the function it was declared in. The addition is the capture list [index], which copies the value at the moment the closure is created; that is the fix for Python's classic late-binding surprise, where every lambda in a loop sees the loop variable's final value and the workaround is a default argument. The capture list is also where [weak self] goes, which is the subject of the memory section.

A protocol is the contract; conforming to it is a declaration a type makes, and the compiler checks that every requirement is met. That is typing.Protocol with teeth: not a hint for a checker to consult, but a condition for the code to exist. Conformance can also be added later and from outside — extension Int: Speaker { } — so you can make a type you do not own satisfy a protocol you wrote, which is the piece Python has no answer for. Note any Speaker, which Swift 5.6 made explicit: it means "some value whose type is only known to conform", and it is boxed and dynamically dispatched.

<T: Comparable> is a constraint: the function accepts any single type that supports <, and both calls above compile to separate specialized versions with no boxing and no dynamic dispatch. The distinction a Python reader most needs is some against any: some Speaker means "one specific type, decided at compile time, which the caller does not get to see", while any Speaker means "any conforming type, decided at run time" and pays for a box and a dispatch. some is what a SwiftUI body returns and is the one to prefer.

This is the mechanism behind the phrase "protocol-oriented programming", and it is the answer to the problem Python solves with mixins and a method resolution order. Any type conforming to Greeter gets greeting() automatically and may override it; a struct can take part, which a base class cannot offer since structs do not inherit. It is also how the standard library works — most of what you can do to a Collection lives in an extension on the protocol rather than in each concrete type.

The synthesized code is generated at compile time from the stored properties, so encoding and decoding are type-checked rather than reflective — and decoding a payload with a missing or mistyped field throws rather than producing an object with a hole in it, which is what Order(**json.loads(text)) does not protect you from. Custom key names go in a nested CodingKeys enum, and keyDecodingStrategy = .convertFromSnakeCase handles the usual API convention in one line. Python's nearest equivalent is Pydantic, which is a library doing at run time what Swift does at compile time.

This is monkey-patching's good half. Nothing is modified: the compiler resolves the call statically, so two libraries can each add an isPalindrome without one clobbering the other, and an extension cannot add stored properties or override existing methods. Python cannot extend a built-in at all — str.isPalindrome = … raises — so the equivalent is always a free function. Extensions are also the standard way to organize a large Swift type: the main declaration holds the stored properties, and each protocol conformance goes in its own extension.

The switch above has no default and compiles, because the compiler can see the two cases are all of them. Add a third and every such switch in the program becomes a compile error pointing at exactly the code that has not been updated — the property Python cannot offer, since a match over a union is never checked for completeness and a missing case silently returns None. Note the leading-dot shorthand: once the type is known from context, .success("data") needs no FetchResult prefix.

: Int gives each case a rawValue, and the initializer Priority(rawValue: 3) is failable — it returns an optional, because there may be no such case, where Python's Priority(3) raises. CaseIterable is what supplies allCases; iteration over an enum is opt-in rather than automatic. Swift enums may also have computed properties, methods and even initializers, but no stored properties, since the case itself is the storage.

Both count references and destroy an object the instant its count reaches zero — so both give you deterministic cleanup, and deinit is __del__. The difference is the cycle. CPython runs a cycle collector in the background that finds unreachable loops and frees them, so the Python column above eventually prints its messages. Swift has no such collector at all: a reference cycle is a permanent leak, and it is your job to break it. That is why the next row exists, and why [weak self] is something every iOS developer types daily.

weak is always optional and becomes nil automatically when the target is freed; unowned is not optional, is slightly faster, and crashes if you touch it after the target is gone, so it is for references you can prove outlive their use. The everyday appearance is the capture list [weak self] on a closure stored by the object it refers to — a view controller holding a completion handler that mentions self is the canonical cycle. Python has weakref and almost nobody reaches for it, because the cycle collector already handles the case.

A function that can fail must be declared throws, and every call to one must be preceded by try — which is not a block, just a marker meaning "this line can throw". Reading Swift, you can see which lines can fail without knowing what the functions do. What Swift does not do is declare which errors, the way Java does, so it is not the checked-exception system its detractors sometimes assume. The other structural difference is that an error is any value conforming to the Error protocol, and an enum is the usual choice, which makes catching a specific case a pattern match.

try? turns a throwing call into an optional, discarding the error — the equivalent of except: pass, but confined to one expression. try! asserts it cannot fail and crashes if it does, and carries the same reviewer's eyebrow as a force unwrap. defer registers a block to run when the current scope exits by any route, and several of them run in reverse order, so cleanup sits next to the acquisition it undoes rather than in a finally far below. Python's nearest equivalent is a context manager, which is more powerful and much more ceremony for a one-line cleanup.

Result is an ordinary enum with a .success and a .failure case, so switching over it is exhaustive and there is no way to use the value without acknowledging the error. It supports map, flatMap and get() — the last of which throws, so you can move between the two styles freely. Python's tuple-of-value-and-error convention is the same idea with nothing enforcing it, since a caller can simply ignore the second element. The rule of thumb in Swift is throws for things that go wrong and Result for a failure you want to store, pass around, or hand to a callback.

Both languages mark a suspending function async and require await at every call to one, so the "function coloring" problem is the same in both and the code looks nearly interchangeable. Swift needs no asyncio.run at the top of a script, since top-level code is itself an async context. The difference underneath is total: Python's coroutines all run on one thread with a single event loop, and Swift's run on a cooperative thread pool with as many threads as there are cores.

The behavior differs where it matters most. Python's gather gives concurrency and never parallelism — one thread, one loop, and a CPU-bound coroutine blocks everything else — which is why heavy work goes to multiprocessing. Swift's child tasks are scheduled onto a real thread pool, so two of them genuinely run at the same instant on different cores; there is no GIL. For a dynamic number of tasks, withTaskGroup is the loop-shaped form, and it — like async let — will not let a child outlive the scope that created it.

An actor is a reference type whose mutable state can only be reached from one task at a time; the compiler enforces it by making every access from outside async, which is why the calls above need await. That converts "remember to take the lock" into "the code does not compile otherwise". Python needs none of this while everything is on one event loop, and needs all of it the moment real threads are involved — where the GIL protects individual bytecodes but not a read-modify-write like value += 1. Swift 6's strict concurrency checking extends the same analysis to every value crossing a task boundary, via the Sendable protocol.

What differs is the producing side. Python's async generator is a function with yield in it and needs no scaffolding; Swift has no async generator syntax, so producing a stream means AsyncStream with a continuation you yield into and must remember to finish(). Consuming is where Swift catches up: AsyncSequence has map, filter, prefix and friends, and Apple's frameworks expose notifications, file lines and network responses as async sequences, so for await line in url.lines is ordinary code.

The mental model is the one a React or Jinja user already has: body is a pure function from the current state to a description of the screen, and the framework re-runs it when the state changes. It is a struct, so the entire view hierarchy is a value that gets rebuilt cheaply and diffed. The trailing-closure rule from the closures section is why VStack { … } and Button("Increment") { … } read as syntax; they are ordinary initializers taking closures.

A property wrapper is a type that intercepts reads and writes of a property, which is roughly what a Python descriptor does, and what @property and @cached_property are built from. Knowing that removes most of the mystery from SwiftUI: @State is a wrapper that stores the value outside the struct and tells the framework to re-run body when it changes. The names to learn are @State for state a view owns, @Binding for state it was lent, and the @Observable macro for a model object several views watch.

There is no file-level namespace: every type declared anywhere in a build target is visible everywhere in that target with no import at all, so import appears only for other modules — Foundation, SwiftUI, a package dependency. You cannot import a single symbol in the usual case, and there is no module object to reference. Nothing executes at import time either, so there are no import-time side effects and no circular-import problem. Access control (private, fileprivate, internal, public) does the encapsulation work that a Python leading underscore only suggests.

The manifest is itself a Swift program, so the dependency list is type-checked. Package.swift holds the version ranges you asked for and Package.resolved holds the exact commits — the split requirements.txt conflates. Dependencies are fetched into the project rather than into a shared environment, so there is nothing to activate and no way to run against the wrong one. There is no central registry: a dependency is a Git URL, which removes an entire class of name-squatting problem and adds the risk that a repository disappears.

#expect is a macro that takes an ordinary boolean expression and, when it fails, reports the values of the sub-expressions — the same trick that makes a bare assert useful in pytest, achieved with macros rather than bytecode rewriting. Tests are plain functions marked @Test rather than methods on a subclass, they can be async and throws, and parameterized tests take an argument list much as @pytest.mark.parametrize does. XCTest is still everywhere in existing projects, so you will read both.