Swift.CodeCompared.To/Python

Identical — and it is the last thing on this page that is. Both languages allow statements at file scope, so neither needs a main. Python has no semicolons, no braces, and no type annotations required anywhere; indentation is not a style choice but the actual block structure, and getting it wrong is a syntax error.

The immutability discipline you have built in Swift has nowhere to live: there is no let, and a SCREAMING_CASE constant is a convention that nothing enforces. A name is a label that can be reattached to any object of any type at any moment, so name = 42 after name = "Ada" is perfectly legal. F-strings (f"{name}") are the interpolation, and they are excellent — they take any expression, and f"{value=}" even prints the expression alongside its value, which is the fastest debugging tool in the language.

The format specification after the colon is the piece worth learning, because it replaces every String(format:) call: {value:.2f}, {count:,} for thousands separators, {name:>10} to right-align, {ratio:.1%} for a percentage. Two more things an f-string does that Swift cannot: f"{value=}" prints value=7, name and all, which is the fastest debugging print in the language; and {value!r} asks for the repr rather than the str. Python's triple-quoted string does not strip leading indentation the way Swift's does, which is why the example is written flush left.

The consequences a Swift developer notices in the first hour: there is no way to write a one-line function body with a real block in it, a stray space is an IndentationError rather than nothing, and mixing tabs with spaces is a hard error since Python 3. Less obviously, this is why Python has no multi-line lambda — an anonymous function would need a block, and a block needs a line of its own — which is the real reason a trailing closure becomes a named def here. Four spaces is the universal convention and black is the tool that stops the argument.

Read the second print in the right column again: double("nope") returns "nopenope", because * on a string repeats it and the int annotation is not enforced by anything. Type hints are checked by a separate tool — mypy or pyright, run in CI or by your editor — and a project that does not run one gets no checking at all. The practical advice for a Swift developer: annotate everything, turn on a strict type checker from day one, and treat it as the compiler you no longer have. It is genuinely good (gradual typing has come a long way), but it is opt-in, and it is not the language.

str | None is the modern spelling of Optional[str] and means the same thing. What runs the check is mypy, pyright or your editor — never the interpreter, which discards the annotations into __annotations__ and carries on. 🚨 Two idioms to be careful with: if found: is not if found is not None:, because an empty string and 0 are falsy, and the same trap makes value or default replace a legitimate 0. Swift's ?? only fires on nil; Python's or fires on anything falsy.

typing.Protocol is the interesting half, because it is what Swift has no direct equivalent of: conformance is structural, so a class matches by having the right methods and never names the protocol. That means a type from a library you do not control satisfies your protocol automatically — which is the problem Swift solves with a retroactive extension, done here by not asking in the first place. None of it exists at run time: announce will happily take anything with a describe, and anything without one fails at the call.

Absence is a value (None) and nothing makes you check for it, so the safety Swift's optionals give you must be recovered with a type checker (str | None is enforced by mypy, and this is the strongest argument for running one). The idioms: x is None rather than x == None, an early return instead of guard let, and the walrus operator (:=) when you want to test and bind in one line. And the error you will meet on your first day is AttributeError: 'NoneType' object has no attribute '…' — that is Python's nil-crash, arriving at run time, in production, exactly where Swift would have refused to compile.

The three real options, none of them as good as ?.: a conditional expression per level, which is correct and gets long; try/except AttributeError, which is short and 🚨 also swallows a genuine typo three levels down, so it hides the bug it looks like it is handling; and getattr(obj, "city", None), which is the same trade with a narrower blast radius. For dictionaries the picture is better — data.get("address", {}).get("city") chains cleanly — which is why deeply nested data is usually kept as dictionaries rather than objects in Python.

if not full_name: covers both of Swift's conditions at once, because an empty string is falsy — convenient here and the exact trap of the previous row when 0 or "" is a legitimate value. What is missing compared to guard is the compiler requiring the branch to leave: a Python if that falls through simply continues, so the shape is a convention. The walrus operator gives back the binding half — if (match := pattern.search(text)) is None: return — and is the closest thing to guard let the language has.

Python has no value types at all, so every assignment aliases and every function receives a reference to your object — mutate it inside and the caller sees it. The defenses are .copy() (shallow) and copy.deepcopy() (recursive), and you must remember to reach for them. Then read the broken function again, because it is the single most famous trap in the language: a mutable default argument is evaluated once when the function is defined, so that list persists between calls and accumulates. Swift's value semantics make both of these unwritable; the Python idiom is items=None plus a check, and it is not optional.

The distinction is the whole row. copy.copy makes a new outer object whose attributes still point at the originals, so changing a nested list is visible through both — which is why shallow.name is private to the copy and shallow.inner.values is not. copy.deepcopy walks the whole graph, handles cycles, and is expensive. The everyday shorthands are the same trade: list(values), values[:] and dict(mapping) are all shallow. Swift never presents the choice, because a value type has no nested reference to share unless you put a class inside it.

The rule with no exceptions: is for None, True, False and sentinels you made yourself; == for every other question. Which small integers and strings happen to be shared is a CPython implementation detail that changes between versions, so code that passes its tests below 257 fails on a larger value — Python 3.8 and later emit a SyntaxWarning for is against a literal, which catches most of it. Note also that defining __eq__ without __hash__ makes the class unhashable, where Swift's Equatable and Hashable are separate on purpose.

Named arguments and defaults are here and are better than Swift's in one respect: any parameter can be passed by name, with no argument label to declare. *args is the variadic (and *list at a call site spreads a list into it, which is Swift's missing spread operator), while **kwargs collects arbitrary named arguments — a thing Swift cannot express at all. The real adjustment is that lambda is one expression only: there are no multi-statement closures, so the trailing-closure style you write constantly in Swift becomes either a comprehension (the idiomatic choice) or a named function defined above.

The two markers are worth memorizing because they are how a Python API expresses what Swift expresses with labels. Everything before / is positional-only — the caller may not name it, which frees you to rename it later without breaking anyone. Everything after * is keyword-only — the caller must name it, which is how you stop clamp(15, 0, 12) from being three anonymous integers. A consequence Swift developers miss at first: because labels are not part of the name, Python cannot overload on them at all; one name is one function, and functools.singledispatch is the deliberate workaround.

Two differences change how code is shaped. Python's sorted takes a key — a function producing a sort key — rather than a two-argument comparator, which is both faster and impossible to get wrong; functools.cmp_to_key exists for the rare case where the comparison really is the only thing available. And a closure may read an enclosing variable but not rebind it without saying nonlocal, where Swift captures by reference by default. The decorator is the idiom worth taking away: @announced is exactly total = announced(total), and it is how logging, caching (@functools.cache) and registration are all written.

The comprehension replaces map, filter, and often reduce, and it works for lists, dicts, and sets with the same syntax. Written with parentheses instead of brackets it becomes a generator — lazy, one element at a time, no intermediate list — which is Swift's .lazy. One difference with teeth: subscripting a dict with a missing key raises KeyError rather than returning an optional, so .get(key, default) is what you actually want (and collections.defaultdict when you want inserts too).

The pairs to memorize: sorted() is sorted(values), contains is the in operator, allSatisfy is all, contains(where:) is any, reduce(0, +) is sum, compactMap is a comprehension with an if, flatMap is a nested comprehension or itertools.chain, and enumerated() is enumerate. 🚨 The one to watch is sorting: values.sorted() returns a new list and values.sort() sorts in place and returns None, so print(values.sort()) prints None — a mistake Swift makes impossible by naming the two differently.

yield is the piece with no Swift counterpart at all: the function suspends at each yield, keeps its local variables, and resumes where it left off — so an iterator that would be a struct with a next() in Swift is three lines here. 🚨 A generator is consumed once, which is the surprise: iterating it a second time yields nothing at all, silently, where a Swift lazy sequence can be walked again. When you need both, keep the list. itertools is the toolbox for the rest — islice, chain, groupby, takewhile, count — and range, zip, map and enumerate are all lazy already.

@dataclass generates __init__, __repr__ and __eq__ from the annotated fields, which covers most of what a Swift struct gives you — but it is still a class, so assignment aliases and replace(instance, field=value) is how you produce a modified copy. The closest thing to real value semantics is @dataclass(frozen=True): immutable, hashable, and safe to share, and it is worth making your default. Note also @property, which turns a method into a computed property accessed without parentheses — the direct translation of Swift's var isAdult: Bool { … }.

Three things to absorb. self is an explicit first parameter of every method — Python does not hide it. There is no access control: a leading underscore is a convention that says "do not touch", and nothing at all prevents you from touching it (a double underscore triggers name mangling, which is obfuscation rather than privacy). And objects are open — you can attach a brand-new attribute to an instance at run time, which is powerful, occasionally useful, and the reason a typo becomes a silently created field rather than an error.

The real value of @property is that it is retrofittable: rectangle.width can start life as a plain attribute and become a validated property later without a single caller changing, which is why Python code does not start with getters and setters the way other languages' does. The leading underscore on _scale is the whole of the privacy story — a convention, enforced by nothing. What is genuinely missing is willSet, lazy var (though functools.cached_property covers the common case) and property wrappers.

Duck typing is the whole story: a function accepts anything with the right method, no conformance is declared, and the check happens when the call runs. That buys enormous flexibility (any object can stand in for any other, which is why mocking in Python is trivial) and costs you the compiler — announce(42) is a perfectly good program until the moment it is not. typing.Protocol is the bridge: it describes the shape you need, and mypy verifies it statically, giving you back something close to a Swift protocol with structural rather than nominal conformance. Python still does not check it at run time.

Every operator and every built-in function is a "dunder" (double-underscore) method: + calls __add__, len(x) calls x.__len__(), for x in thing calls __iter__, thing[0] calls __getitem__. That is Python's answer to Swift's standard-library protocols (Equatable, Comparable, Collection), and it is the whole language in one idea — implement the right dunder and your type works with the built-in syntax. Nothing declares that you conform to anything; you just define the method.

The three tools sit on a line. Duck typing checks nothing until the call. typing.Protocol from the previous section checks structurally, in a type checker, with no inheritance — closest to what a Swift protocol feels like. ABC checks at run time, at the moment you try to instantiate, and requires the subclass to say it inherits. Choose Protocol when the implementations are not yours to change, and ABC when you own the hierarchy and want the failure loud. Neither gives you Swift's guarantee, which is that the program does not build at all.

match is genuinely good: it destructures classes as it matches (case Circle(radius=radius)), it takes guards (if), and it goes further than Swift by matching the shape of dicts and lists — which is exactly what you want when handling decoded JSON. What it does not have is exhaustiveness: nothing tells you a case is missing, so case _ is doing real work, and adding a third shape silently falls into it. That guarantee — the one that makes Swift enums so safe to extend — has no Python equivalent, though a strict mypy setup can approximate it with assert_never.

Python enums carry values (the rawValue), are iterable without asking (allCases for free), and can hold properties and methods. Two notes: constructing from a value raises ValueError on a miss rather than returning an optional, and members are singletons, so is is the idiomatic comparison. What Python's Enum cannot do is carry per-case associated values — for that you are back to the dataclasses-plus-match pattern in the previous concept.

Dataclasses plus match get the shape back, and the guarantee does not come with them: the case _ arm exists because nothing can prove the list is complete, so adding a third shape is a run-time ValueError rather than a build failure. That discard arm is the idiom precisely because it turns a silent wrong answer into a loud one — leaving it out makes match fall through and return None. A type checker can be told to help with typing.assert_never in the final arm, which is as close to exhaustiveness as Python offers.

The throws annotation is gone, so a function's signature no longer tells you it can fail — and in Python that is a bigger deal than it sounds, because exceptions are used for ordinary control flow: a missing dict key raises, a failed int() raises, and iteration itself ends with a StopIteration. The cultural name for this is EAFP ("easier to ask forgiveness than permission"): the idiomatic move is to attempt the operation and catch the failure, where a Swift developer's instinct is to check first. Both languages have finally, and neither has checked exceptions.

Python has no defer. Cleanup is attached to a resource rather than a scope: with resource: calls __enter__ on entry and __exit__ on every exit path, including an exception — which is why with open(…) is how every file in Python is opened. For the general case (run this code on the way out, whatever happens), @contextmanager turns a generator into one: everything before the yield is the entry, everything in the finally is the exit. It is more ceremony than defer for a one-off, and better than defer when the cleanup belongs to a thing rather than to a block.

The hierarchy is what a Swift enum of errors cannot do: except ConfigurationError catches every subclass, except ValueError catches those plus anything else meaning "bad value", and a caller that wants to distinguish them still can. The else clause is the underused one — it runs only when the try block raised nothing, which keeps the success path out of the block being guarded, so an exception raised by print(value) is not accidentally caught by the handler above it. raise … from None suppresses the chained ValueError; from error keeps it when the cause is worth showing.

The syntax ports one-for-one — async def, await, and asyncio.gather for awaitAll — and then the Global Interpreter Lock changes what it all means. Only one thread runs Python bytecode at a time, so asyncio gives you concurrency (thousands of overlapping I/O waits on a single thread) but never parallelism. CPU-bound work needs multiprocessing, which forks real processes and pickles the arguments across the boundary — closer to Elixir's isolation than to Swift's task group. The rule of thumb: asyncio for waiting, multiprocessing for computing, and threads almost never. (The GIL is finally becoming optional in 3.13+, but assume it is there.)

The decision procedure is short. Work that waits — network, disk, a subprocess — releases the lock while it waits, so threading and asyncio both help, and asyncio scales further because a coroutine is far cheaper than a thread. Work that computes needs separate interpreters: multiprocessing, concurrent.futures.ProcessPoolExecutor, or pushing the loop into C by way of numpy. Python 3.13 added an experimental free-threaded build with no lock at all, and 3.14 made per-interpreter subinterpreters available from Python — both real, neither yet the default, so the rule above is still the one to plan around. Nothing here corresponds to a Swift actor: shared state is protected by a threading.Lock you remember to take.