Haskell.CodeCompared.To/Python

That immediacy is the first real difference in feel: there is no compile step, no IO () to be inside, and no distinction between a declaration and an action. It also means a module's top level is an effect — importing a file runs every statement in it, which is why the if __name__ == "__main__" guard exists and why import-time side effects are a real hazard in Python codebases.

This is the shape of nearly every loss on this page, so it is worth sitting with once: a Haskell programmer's confidence comes from the compiler having read everything, and Python's does not exist by default. The replacements are real but opt-in and partial — mypy or pyright catch the name and most type errors, ruff catches a broad class of mistakes, and tests catch what neither does. A serious Python codebase runs all three in continuous integration, which is the closest thing available to the guarantee you are giving up.

The IO type disappearing is the single largest thing a Haskell programmer gives up, and no Python feature replaces it. What replaces it is discipline that experienced Python programmers already practise for their own reasons: keep functions small and pure where you can, push input and output to the edges, pass dependencies in rather than reaching for globals, and make anything that mutates say so in its name. That is the same architecture you would build in Haskell — it is simply not enforced, so a code review is the type checker.

So the habit to build is to notice which operations mutate. list.append, list.sort, dict.update and set.add all modify in place and return None; +, sorted and a comprehension all build something new. Choosing the second kind gets you most of Haskell's reasoning back. For data that must not change there are tuple, frozenset and @dataclass(frozen=True) — all genuinely immutable, and all worth reaching for.

The recovery is a separate tool: mypy or pyright read the same annotations and reject that second call, and a project that runs one in continuous integration gets a meaningful fraction of the guarantee back. Two things that do not come back: there is no inference across a whole program, so an unannotated function is simply unchecked, and there is nothing like a type class constraint driving which implementation runs — annotations never affect behavior. Write them anyway; they are the best documentation Python has.

The stronger option is a frozen dataclass wrapping the value, which is a real distinct type at run time and costs an allocation and an attribute access. That is the trade to weigh per case: NewType is free and checked only by a tool, a wrapper class is real and costs something. Neither gives you the deriving machinery, so __eq__ and __hash__ come from the dataclass decorator rather than from deriving (Eq, Ord).

The correspondence is closer than it looks — take is itertools.islice, iterate is itertools.accumulate, cycle and repeat keep their names, and zip is lazy in Python 3. What is genuinely gone is laziness by default: a Python list comprehension builds the whole list, so an accidental list(naturals()) hangs, and there is no equivalent of a lazily-defined recursive value such as fibs = 0 : 1 : zipWith (+) fibs (tail fibs). In exchange, evaluation order is obvious and there are no space leaks to reason about.

This is worth naming as a genuine gain rather than a consolation. Python's memory behavior is what the code says: a comprehension allocates its list, a generator does not, and there is nothing deferred waiting to be forced. range is the one thing that behaves lazily and it is a special object rather than a general mechanism. The cost is the other side of the same coin — you cannot express a computation that produces only as much as is demanded without writing a generator on purpose.

The idiomatic Python is usually neither partial nor a lambda but a comprehension, which is why the second line reads the way it does — map and filter exist and lose to comprehensions on readability nearly every time. The habit to unlearn is point-free style: it does not survive the trip, and code written that way reads as obscure to Python programmers rather than as elegant.

The generic compose at the bottom is written out to make a point: it is possible, it is in nobody's codebase, and reaching for it marks the code as foreign. The Python instinct is to name intermediate steps with ordinary variables rather than to build a pipeline value, and taking that instinct seriously is what makes Haskell-influenced Python readable to the people maintaining it. There is no $, so parentheses are the whole story.

The specialized folds are the idiom instead: sum, max, min, any, all, math.prod, and sum(1 for … if …) for counting. That covers the great majority of real folds, and reaching for reduce where one of them applies is the clearest sign of a functional programmer writing Python. There is no foldr at all, because without laziness a right fold over a large list has no advantage and a real stack cost.

This is the closest correspondence on the page and the feature most worth adopting on day one: @dataclass(frozen=True) gets you a value type with structural equality and no mutation, which is most of what a Haskell record gives you. What is missing is deriving (Ord) unless you pass order=True, and anything like Generic-derived serialization — for which the ecosystem answer is pydantic, which also validates at run time.

🚨 That raise is there because nothing checks exhaustiveness at run time. Adding a third shape and forgetting a case produces a function that falls off the end and returns None — so the explicit raise turns a silent wrong answer into a loud failure, and it is the idiom to adopt. A type checker can verify exhaustiveness using typing.assert_never in the final branch, which is the closest thing to -Wincomplete-patterns and is worth setting up if the codebase leans on unions.

What is missing: no exhaustiveness check, no matching on a function's parameters (so one function with a match replaces several equations), no where clause, no as-patterns spelled with @ in the Haskell sense (Python's case [first, *rest] as whole does exist and works differently), and no view patterns. A subtle one worth knowing: a bare name in a case is a binding, not a comparison, so case circle: matches everything and shadows the variable — compare against a dotted name or a literal instead.

match also takes guards (case value if value < 0:), which is closer to the Haskell spelling and worth using when the branches are structural rather than numeric. Two absences: no otherwise (the last return is it), and no where clause, so a helper value used by several guards becomes a local variable computed before the chain — which is often clearer anyway.

The differences are worth being precise about. An instance is chosen by the value's type here, so there is no return-type polymorphism — nothing like read :: Read a => String -> a or mempty, where Haskell picks the instance from the context. There is no coherence guarantee, so two libraries may define conflicting behavior for the same class. And there are no superclasses, no default methods that dispatch, and no deriving. What you gain is that a type can satisfy a protocol written years later, by anyone, without either side knowing.

order=True on the dataclass generates the comparison methods from the field order, which is deriving (Ord). Two Python specifics: __str__ is for humans and __repr__ for developers, and print uses the first while the interactive prompt uses the second — Show is closer to __repr__. And overriding __eq__ without __hash__ makes the type unhashable, which the dataclass decorator handles correctly when the class is frozen.

That inversion changes which algorithms are natural. The Haskell habit of building a result by prepending and reversing at the end becomes append with no reverse, since appending is amortized constant. Recursion over head and tail becomes a loop or a comprehension — and should, because Python has a recursion limit around a thousand frames and no tail-call elimination. collections.deque is the answer when you genuinely need both ends.

Two additions on the Python side worth knowing: the same syntax in braces builds a set or a dict ({key: value for …}), and in parentheses builds a lazy generator. What is missing is pattern matching in the generator — [x | Just x <- values] has no equivalent, so filtering out None is an explicit if value is not None. And there is no monad comprehension: the syntax works on iterables only.

.get is the Maybe-shaped lookup and returns None for a missing key; counts[key] raises KeyError, which is the total-versus-partial distinction made explicit at the call site. Two differences from Data.Map: a dict preserves insertion order rather than sorting by key (hence the sorted above), and there is no persistent map in the standard library, so "a new map with one more entry" means copying or reaching for a library such as immutables.

A type checker does enforce it — mypy rejects found + 1 without a narrowing check, and that is the single most valuable thing static typing buys in Python. What is gone is the rest of the Maybe machinery: no fmap over it, no >>=, no maybe function, no traverse. The Python shape is an early if value is None: return None, which is the do-notation unrolled by hand.

This is a real change in how a program is structured, and Python's version has a genuine advantage worth acknowledging: an error that most callers cannot handle does not have to be threaded through every signature between the failure and the handler. What is lost is that the type no longer tells you a call can fail, so the discipline is documenting it and catching narrowly — except ValueError rather than except Exception. Libraries such as returns provide a real Result type; they are a minority taste and reviewers will push back.

The habits that make this comfortable are the ones a Haskell programmer already has, aimed slightly differently: prefer the total variant where one exists (dict.get, next(iterator, default), a slice values[:1] rather than values[0]), and catch narrowly where it does not. Python's culture leans the other way — "easier to ask forgiveness than permission" means try it and catch the failure — and that is idiomatic here even though it reads as reckless coming from Haskell.

For a Haskell programmer the loss is not the syntax but the boundary: IO made it impossible to accidentally perform an effect inside a pure calculation, and nothing here prevents that. The architecture that survives is functional core, imperative shell — pure functions doing the work, a thin outer layer doing the reading and writing — which is exactly what IO encouraged and is regarded as good design in Python for its own reasons: it is what makes code testable without mocking.

The honest replacements are ordinary: thread the value explicitly (which is what State desugars to anyway), or use a class to hold it, which is what a Python programmer will write and expect to read. contextvars covers the Reader-shaped case of ambient context, and is what asynchronous frameworks use for request-scoped values. Note that >>= on Maybe, the most common everyday monad, becomes early-return None checks — which is less elegant and perfectly clear.

Two things worth carrying in with you. First, the habits transfer even though the guarantees do not — small pure functions, immutable data, effects at the edges and total functions are all recognized as good Python, and code written that way is easier for Python programmers to review rather than harder. Second, the tooling gap is narrower than it looks: mypy or pyright in strict mode, ruff, and hypothesis for property-based testing (which is QuickCheck, by the same idea and a good implementation) recover a real fraction of what the compiler was doing.