OCaml.CodeCompared.To/Python

OCaml's let () = … binds the unit pattern, which runs the expression and asserts it produces nothing. Python has no such notion: a module is a sequence of statements executed top to bottom when it is imported or run. The deeper difference is the one that shapes everything else on this page — the OCaml line has been type-checked before it runs, and the Python line has not been checked at all. print here is resolved when the line executes, not before.

OCaml's format string is a typed value: the compiler reads %s and %d and requires exactly a string then an integer, so a mismatch is a compile error. Python's f-string calls str() on whatever each expression evaluates to, so nothing can mismatch and nothing is checked — f"{name} {year}" would work with the arguments swapped, printing something wrong rather than failing. In exchange the syntax embeds arbitrary expressions (f"{year + 1}", f"{value:.2f}") that OCaml would need sprintf and explicit arguments for.

An opam switch and a Python virtual environment are the same idea: a per-project directory of installed packages, activated in the shell, so two projects can want different versions of one library. Both also mean a build depends on machine state the project files do not fully record. The difference is that OCaml compiles, so a missing or mismatched dependency is a build error, while Python resolves imports at runtime — a package missing from a rarely-taken code path fails when that path is first taken, possibly in production.

OCaml checks every expression before the program starts, so a type error is a compile error naming the line. Python checks nothing ahead of time: names are resolved and operations are attempted at the moment the line executes, and an error surfaces only if that line runs. The practical consequence for someone arriving from OCaml is that test coverage takes over the job the type checker was doing — a branch nobody executes is a branch nobody has checked. Python's answer is threefold: tests, type hints with an external checker (see the type-hints section), and a REPL that makes the feedback loop very short.

OCaml's variant closes the set: shape has exactly two constructors, the compiler proves area handles both, and adding a third breaks the build until it is handled. Python's version is open — any class with an area method can join, from any library, with no coordination — and correspondingly unchecked, since nothing verifies that a given object has the method until the call happens. Each direction is genuinely useful. The OCaml habit that transfers badly is reaching for a closed variant when the Python answer is a protocol; the Python habit that transfers badly is assuming an object has a method because it usually does.

In OCaml only bool may be a condition, so emptiness has to be asked for explicitly. Python treats 0, 0.0, "", [], {}, set() and None as false and everything else as true. The idiom if not items is genuinely more readable than the OCaml line above — and the trap is that it does not distinguish "empty" from "absent". A function returning either a list or None passes both through the same branch, which is exactly the confusion option exists to prevent. When the difference matters, write if items is None.

OCaml's let introduces a fresh binding over a new scope, so the earlier count still exists and any closure that captured it still sees 10. Python's = rebinds the name in the enclosing namespace, so nothing sees the old value afterwards and a closure that captured the name sees the new one. That difference is invisible until a closure is involved, at which point it produces the most-reported surprise in the language — a loop that builds functions, all of which end up seeing the loop variable's final value.

An OCaml int is 63 bits — one bit is the garbage collector's tag — and it wraps silently on overflow, so a computation that exceeds it produces a wrong answer with no indication. Python integers grow to whatever size is needed, so 2 ** 200 is exact and nothing overflows, at the cost of every arithmetic operation going through a heap object rather than a machine word. When OCaml needs the same thing it reaches for the zarith library. Note also that Python's / always produces a float; integer division is //, which is closer to OCaml's /.

OCaml's int option is a different type from int: you cannot add one to a number without unwrapping, and the compiler lists the case you forgot. Python's None is just another value the same name might hold, so found + 1 compiles fine and raises TypeError only if find_even happened to return None on that run. Note also is not None rather than != None: is compares identity, which is the correct test for a singleton, and it cannot be overridden by a class that defines a strange __eq__.

Both languages build a tuple with a comma and take one apart by pattern. Python's tuple is immutable, which makes it the one place in the language where an OCaml programmer's expectations about immutability hold — lists, dictionaries and sets are all mutable. Python also allows a starred element (first, *rest = [1, 2, 3]) which OCaml would express with a list pattern, and it uses tuples so freely that returning several values is the ordinary way to write a function with more than one result.

An OCaml string is a sequence of bytes with no declared encoding, so String.length counts bytes and an accented letter counts as two. A Python str is a sequence of Unicode code points, so len counts characters as a human would for most scripts. Python separates bytes into their own type (bytes, written b"…") and refuses to mix the two without an explicit encode or decode — which is exactly the discipline OCaml leaves to the programmer.

Python's [start:stop:step] works on any sequence — strings, lists, tuples, and library types like NumPy arrays — with every part optional, negative indices counting from the end, and a negative step reversing. OCaml's String.sub takes an offset and a length rather than a second index, which is a persistent source of off-by-one confusion when translating in either direction, and it has no step at all. This is a case worth adopting rather than resisting: reaching for a slice is the idiomatic Python answer far more often than an OCaml programmer expects.

Python's string methods are called on the value (line.split), which makes them discoverable by typing a dot in a REPL — a real advantage for learning a library. The join is worth noting because it reads backwards to almost everyone at first: the separator is the string you call it on. OCaml's String.concat takes the same two arguments in the same order and looks less surprising because it is a plain function. Python also has .strip(), .replace(), .startswith() and dozens more built in, where OCaml's String module is deliberately minimal.

The two types share a name and almost nothing else. OCaml's is an immutable linked list: 0 :: numbers builds a new list sharing the old one's cells, so numbers is unchanged and both exist. Python's is a mutable dynamic array: insert(0, …) shifts every element and modifies the list in place, so there is no old version to refer to. len is free in Python and a full traversal in OCaml; appending is cheap in Python and expensive in OCaml, and the reverse is true for prepending. The habit to break is building a result by consing and reversing at the end — in Python you append, and it is already in order.

Both are hash tables and both offer a lookup that reports absence rather than raising — OCaml's find_opt returning an option, Python's .get returning None. Two Python details matter. Since Python 3.7, dictionaries preserve insertion order, which OCaml's Hashtbl does not promise. And ages["missing"] raises KeyError where .get returns None, which is the same raising-versus-option pair OCaml offers as find and find_opt. Dictionaries are far more central in Python: they carry keyword arguments, object attributes and JSON, so an OCaml programmer will meet them constantly.

OCaml's Set.Make (Int) builds a module specialized to integer elements, and every operation goes through it. Python's set is a builtin whose elements need only be hashable, with |, &, - and ^ for union, intersection, difference and symmetric difference. The trade is the usual one: OCaml's set is persistent, so union allocates a new set and leaves both operands intact, while Python's is mutable — first |= second modifies first in place, and any other name referring to it sees the change.

OCaml's List.sort takes a comparison returning a negative number, zero or a positive one — the C convention. Python's sorted takes key=, a function computing the value to sort by, and calls it once per element rather than once per comparison. That is both faster for an expensive key and much harder to get wrong, since there is no three-way convention to remember. Python also accepts reverse=True, and its sort is stable — as is OCaml's List.stable_sort, though plain List.sort makes no such promise.

OCaml supplies List.iteri and List.iter2, plus mapi and map2, each specific to one module and one arity — and iter2 raises if the lists are different lengths. Python's enumerate and zip are generic lazy iterators usable with any iterable, in a comprehension, or passed onward; zip stops at the shorter input silently, and zip(…, strict=True) asks for OCaml's raising behavior. enumerate(words, start=1) shifts the index, which is worth knowing because writing range(len(words)) and indexing is the mark of someone still thinking in another language.

In OCaml the question does not arise: a list cannot be modified, so two names for one list are indistinguishable from two lists. In Python alias = original copies a reference, and every mutation through either name is visible through both. A shallow copy is original[:], list(original) or original.copy(); a deep copy needs copy.deepcopy. The rule worth internalizing is that assignment never copies in Python — it binds a name to an existing object — and that this is invisible until something mutates.

OCaml evaluates an optional argument's default expression at every call, so ?(into = []) gives a fresh empty list each time — which is what anyone would assume. Python evaluates the default once, at definition time, and stores the resulting object on the function, so a mutable default is shared across every call that omits it. The output above shows the counter climbing 1, 2, 3 instead of staying at 1. The fix is universal: default to None and build the real default inside the body. Linters flag this, and it still gets written.

@dataclass(frozen=True) makes assignment to a field raise FrozenInstanceError, and dataclasses.replace is exactly OCaml's { record with field = value }. Freezing also makes the instance hashable, so it can be a dictionary key or set element. This is the closest Python gets to an OCaml record and is worth reaching for by default when the data is not meant to change — the language will not suggest it, since every other container is mutable and nothing warns.

In OCaml everything produces a value, so if, match and even a for loop (producing unit) can appear wherever a value is expected. Python's if, for, while and try are statements that produce nothing, so the branches have to assign to a name. The conditional expression a if condition else b covers the two-branch case and does not chain readably beyond that. The related consequence is that a Python lambda may contain only an expression, which is why Python code uses named functions where OCaml would inline one.

OCaml's for … to … done counts, and iterating a collection means List.iter. Python's for only ever iterates something iterable, and range(1, 4) is a lazy sequence that stops before its upper bound — the half-open convention, which catches every newcomer once. The while counter is an ordinary rebindable name in Python and needs a ref in OCaml, because OCaml has no mutable local bindings. Both languages have break and continue… except that OCaml has neither, which is worth knowing before looking for them.

OCaml guarantees tail-call elimination, so an accumulator-passing recursion runs in constant stack space and recursing a hundred thousand deep is unremarkable. Python performs no tail-call elimination at all — deliberately, so that stack traces stay complete — and enforces a recursion limit of about 1000 to turn stack exhaustion into a catchable exception rather than a crash. Raising the limit with sys.setrecursionlimit is possible and mostly a way to get a real segfault instead. Where an OCaml programmer writes a recursive helper, Python writes a loop, and that is idiomatic rather than a concession.

In OCaml add 10 is not a special form — add genuinely has type int -> int -> int, so applying it to one argument is ordinary application. Python has no currying: a two-parameter function must receive two arguments, and calling it with one raises TypeError. functools.partial covers the common case and a lambda covers the rest. The knock-on effect is that OCaml's point-free pipelines built on |> do not survive translation, and Python reaches for a comprehension or a loop where OCaml would compose functions.

OCaml labels an argument with ~ and defaults it with ?, and needs a trailing () because a function with optional arguments cannot otherwise be known to be fully applied. Python needs no such marker: any parameter can be passed by name, defaults are written inline, and the call is unambiguous because there is no partial application to disambiguate against. Python also has *args and **kwargs for variadic and keyword-variadic parameters, which OCaml has no equivalent for at all — and remember from the mutability section that a default value is evaluated once, not per call.

OCaml's fun and its named functions are the same thing, so an anonymous function can hold local bindings, sequencing and matching — anything at all. Python's lambda is limited to a single expression, because assignment and control flow are statements and a lambda body must be an expression. That is a deliberate design decision rather than an oversight: the language pushes anything non-trivial into a named def, on the grounds that it then has a name and a docstring. The practical effect is that Python code is less densely functional than OCaml code even where the same approach would work.

Both columns wrap a function in logging, and both are just higher-order functions. What Python adds is the @ syntax, which applies the wrapper at the point of definition so that every caller gets the wrapped version without changing any call site. OCaml can express the wrapping, as the anchor column shows, but has no way to make it the definition — callers would have to call with_logging "double" double explicitly. Decorators carry a large amount of real Python: @property, @staticmethod, @dataclass, @functools.cache, and every web framework's routing.

OCaml's fun number -> … introduces a new binding per call, so each closure captures a different number and the three functions return 10, 20 and 30. Python's for loop rebinds one variable, and a closure captures that variable rather than its value at capture time — so after the loop all three see 3 and all three return 30. The output above shows exactly that: [30, 30, 30] then [10, 20, 30]. The idiomatic fix is the default-argument trick shown, which evaluates number at definition time; a comprehension avoids the problem because each iteration of a comprehension does get its own scope.

The two columns produce the same pairs. Python's comprehension reads as set-builder notation: the result expression first, then generators, then filters, with each additional generator costing one line rather than one nesting level. OCaml has to compose concat_map with filter_map and indent for each. Python has the same syntax for dictionaries ({key: value for …}), sets ({value for …}) and generators (parentheses instead of brackets). This is one of the clearest ergonomic wins Python has over OCaml, and it is used constantly.

OCaml's Seq.t is a function returning a node on demand, and building a custom one means writing that function or composing existing combinators. Python's yield turns a whole function into a generator: it runs until the yield, hands back a value, and resumes exactly there on the next request, with its local variables intact. That makes complex lazy producers — a parser, a tree walk, a paginated API reader — dramatically easier to write than the equivalent unfold. It is the same capability OCaml 5's effect handlers provide, exposed as one keyword instead of as a general mechanism.

OCaml's pipeline reads left to right and allocates a new list at each stage. Python's generator expression — the comprehension without brackets, passed straight to sum — does the whole thing lazily in one pass with no intermediate list at all. map and filter do exist as builtins, but combining them reads worse than the comprehension and the community regards them as a foreign accent. functools.reduce is OCaml's fold_left, and it is deliberately tucked away in a module because a named builtin (sum, max, any, all) is nearly always clearer.

OCaml's objects are structurally typed and genuinely interesting, and real OCaml code hardly touches them — records, variants and modules cover the ground. Python has no alternative: a class is how you group data with behavior, and every library you use is built from them. The explicit self as the first parameter of every method is the visible sign that a method really is a function taking the object, which is exactly what the OCaml column's deposit account amount is — Python just puts it inside the class and gives it dot-call syntax.

An OCaml record's fields are fixed by its type, so point.z is a compile error and so is a misspelling of x. A Python instance keeps its attributes in a dictionary (vars(point) above), so point.z = 3 simply adds one — and self.balnce = 0 in a constructor silently creates a second attribute beside balance, which then reads as zero forever. The defense is __slots__, which fixes the attribute set and rejects anything else, or a @dataclass, or a type checker. None of them is on by default.

OCaml has no operator overloading at all — which is why floats need +. and *., and why a custom type gets named functions instead. Python resolves + by calling __add__ on the left operand, len(x) by calling __len__, print(x) by calling __str__, and for … in x by calling __iter__. That is the whole reason NumPy arrays and pandas DataFrames read as naturally as they do. The cost is the usual one: + means whatever the object decides, so reading unfamiliar code requires knowing the types involved.

OCaml has class inheritance in its object system, and idiomatic OCaml does not use it — the two natural answers are a variant when the set of kinds is closed and known, and a record of functions when it is open. Python's answer to both is subclassing, and it is what every library expects. The trade is the familiar one: the OCaml variant makes the compiler prove every kind is handled, while the Python hierarchy is open to subclasses from anywhere and checks nothing until sound() is actually called — which is what NotImplementedError is standing in for.

@dataclass generates __init__, __repr__ and __eq__ from the annotated fields, so construction, printing and structural equality all work — which is what OCaml gives every record without asking. dataclasses.replace is { record with field = value }. Two differences remain: the annotations are not enforced at runtime, so Point("a", "b") constructs happily, and the instance is mutable unless you add frozen=True. OCaml's structural equality comes from the polymorphic =, which works on any type by inspecting representations — including ones where it should not, such as functions, where it raises.

A NamedTuple is a tuple — it unpacks, compares and hashes like one — while also giving its positions names. OCaml has no need for the category because a record is already lightweight, immutable and structurally comparable, and there is no cost to declaring one. The one thing the Python version offers that an OCaml record does not is that it remains a sequence, so it works anywhere a tuple works. Choose NamedTuple for immutable value objects and @dataclass when you want mutability, defaults or methods.

The match statement matches class patterns, sequences, mappings and literals, binds sub-patterns, and supports | alternatives and if guards. What it does not do is check exhaustiveness: delete the Point() case and nothing complains, the match simply falls through and the function returns None, which then flows onward as a number until something adds to it. That trailing return None in the target column is not decoration — it is what Python does implicitly, made visible. Adding a fourth shape to the OCaml column is a compile error listing the unhandled constructor; in Python it is a silent behavior change.

OCaml's constant constructors are just a variant with no arguments, so exhaustiveness applies to them like anything else. Python's Enum gives named constants with values, iteration over the members, and identity comparison with is — but no exhaustiveness anywhere. The relevant gap is that an OCaml variant can carry data per constructor (Circle of float) while an Enum member cannot vary its shape; that is why the previous row used dataclasses rather than an enum. Python has no single construct that does both jobs.

The correspondence is good: an empty pattern, a fixed-length pattern binding its elements, and a pattern binding the front with a starred rest. Python's *_ can appear anywhere in the sequence, including the middle ([first, *middle, last]), which OCaml cannot express in a list pattern at all. What Python cannot do is prove the three cases are exhaustive — the return "unmatched" is there because nothing else guarantees a value comes back. Python also matches dictionaries by key, which OCaml has no pattern syntax for.

OCaml modules nest, can be defined inline, can be passed to functors and packed into values. Python modules are files in directories, created as objects the first time they are imported — and the import runs the file's top-level code, which is why a module with side effects at the top level is a design error and why if __name__ == "__main__": exists. Python has no nested modules, no signatures and no functors; what it has is a very large standard library and an even larger index of third-party packages, which is a substantial part of the reason to learn it.

An OCaml functor exists to say "this code works for any type that supports these operations," and to have the compiler check that claim. Python makes the same code work for anything at all and checks nothing: largest above works on numbers and on strings, and on a list of mixed types it raises TypeError at the comparison. That is the exchange in one row — enormous flexibility for no guarantee. Python's partial answer is the typing.Protocol class, which describes a structural interface that a type checker can verify statically; it is opt-in, and it is covered in the type-hints section.

Counting occurrences and sorting by frequency is fifteen lines of hand-rolled hash-table work in OCaml and one Counter in Python — and JSON serialization, which OCaml needs an opam package for, is one import. The standard library ships date handling, regular expressions, CSV, SQLite, HTTP, compression, subprocess control, statistics and much more, and PyPI carries the rest. OCaml's library is small on purpose, with a rich opam ecosystem outside it; the practical difference is that in Python the thing you need is usually already installed. This is a real advantage and it is why so much data work happens here.

OCaml declares an exception with a keyword and catches it by pattern in a try … with. Python's exceptions are classes inheriting from Exception, caught by type with except, and they carry a traceback. The cultural difference is scale: because Python has no option or result in general use, exceptions carry nearly all error handling — a missing dictionary key, a failed parse, a file that is not there, and the end of an iterator are all exceptions. Python also has finally and the with statement for cleanup, where OCaml offers Fun.protect.

OCaml's result puts the failure in the type, so the caller cannot reach the value without deciding what to do about the error — the compiler will not let a failure be ignored. Python has no such convention: the standard library raises, third-party libraries raise, and a caller who writes no try simply lets the exception travel up. That is not always worse — an error that nobody can handle locally is better propagated than threaded through every signature — but it does mean the set of exceptions a function may raise is documentation rather than type. Note that NotPositive subclasses ValueError so one except catches both failures, which is the standard way to build an error hierarchy.

OCaml's Fun.protect takes the body as a function and a ~finally to run afterwards, which works but reads as a higher-order call. Python's with statement is syntax: the object it is given has its cleanup run when the block ends, however it ends. @contextmanager turns a generator into one — everything before the yield is setup, everything after is teardown — so writing one is short. This is why Python code opens files as with open(path) as file: rather than remembering to close them, and it is a pattern worth adopting wholesale.

The annotation value: int is stored on the function and otherwise ignored: double("ab") runs and returns "abab", because str * 2 is a valid operation. Nothing in the interpreter enforces a hint, ever. What makes hints useful is an external checker — mypy, pyright or the one built into an editor — run as a separate step, the way a linter is. Used seriously across a whole codebase, that recovers a genuine fraction of what OCaml gives you. Used partially, it recovers a smaller fraction, because a function with no hints is treated as accepting and returning anything.

int | None is a union type, spelled with | since Python 3.10 and as Optional[int] before that. To a checker such as mypy it behaves much like OCaml's int option: writing found + 1 without first narrowing is reported as an error, and the if found is not None above is what narrows it. The differences from OCaml are that there is no wrapper — a present value is the integer, with no Some to unwrap — and that all of it is advisory, since the interpreter runs the code either way.

A Protocol is structural: Square does not inherit from Shaped or mention it, and it satisfies the protocol simply by having a matching area. That is much closer to OCaml's structurally-typed objects than to its module signatures, and it is genuinely useful — it lets an existing class from a library satisfy your interface without modification. What it does not do is carry an abstract type the way module type Shaped's type t does, and like every hint it binds only the checker.

OCaml infers 'a list -> 'a -> 'a with no annotation, and generalizes automatically — parametric polymorphism is the default, not a feature you reach for. Python 3.12 introduced the [T] syntax that declares a type variable inline (earlier versions needed TypeVar imported from typing), and a checker uses it to relate the argument types to the result. At runtime it means nothing at all: both calls above would work identically with every annotation deleted. The genuine benefit is that a checker will now reject first_or([1, 2], "zero"), which is a real mistake it would otherwise miss.

OCaml 5's Domain is an OS thread with its own minor heap, and several domains genuinely run at once. Python threads are also OS threads, but the global interpreter lock has meant that only one executes Python bytecode at a time, so CPU-bound work gets no speedup from them at all — they help only when threads are waiting on input and output, which releases the lock. The escape has traditionally been multiprocessing, which forks separate interpreters. This is changing: recent Pythons ship an optional free-threaded build with no lock, but it is not yet the default and library support is still arriving.

Both columns print the same three lines, and everything that matters is in the code that produced them. Python's async/await is a compile-time transformation into a state machine, and it colors functions: task must be async to suspend, main must be async to await it, and asyncio.run is needed to start the chain — so introducing one asynchronous call at the bottom means changing every function above it. OCaml 5's task is an ordinary function with an ordinary type that suspends anyway, because the handler rather than the callee decides what suspension means. That is why OCaml 5 has no async keyword and why libraries such as Eio present blocking-looking APIs that do not block. The OCaml column shows the raw mechanism rather than a scheduler, since the scheduler is a library.

Neither language ties the lock to the data, so deleting the locking in either column leaves a program that compiles, runs, and quietly loses increments. Python's with lock: is at least harder to unbalance than OCaml's explicit Mutex.lock/Mutex.unlock pair, since the release happens however the block exits. The global declaration is worth noting: without it, total += 1 would create a local variable rather than rebinding the module-level one, and the function would raise UnboundLocalError — assignment anywhere in a function body makes that name local for the whole body.