Fortran.CodeCompared.To/Python

🚨 implicit none is worth a moment, because its absence is the closest thing Python has to a Fortran hazard. It is the line that stops Fortran inventing a variable from a typo; Python has no such line and will create a variable on first assignment — so totl = 0 followed by total += 1 raises NameError only when the second line runs, and a misspelling on the left-hand side creates a second variable silently. A linter is the substitute.

For scientific code this matters in a specific way: a rarely-taken branch is often the error path, so the bug surfaces during the run that already went wrong. The replacements are real and opt-in — ruff catches undefined names in seconds, mypy or pyright catch type mismatches, and both belong in the project from the first day. What Python gives back is the other half of the loop: no compile step at all, so an idea and a plot are thirty seconds apart.

A Python list is not an array: it is a growable sequence of pointers to arbitrary objects, so it cannot do elementwise arithmetic and would be slow if it did. NumPy is the actual counterpart to a Fortran array — a typed, fixed-shape, contiguous block with whole-array operators — and the next row shows it. Do not port Fortran array code to Python lists; the result will be correct, unrecognizable and roughly a hundred times slower.

The correspondence is not a coincidence — NumPy was designed by people who wanted Fortran's array model in Python, and numpy.linalg calls LAPACK, which is Fortran. So the honest framing of this whole page is that moving to Python means moving to NumPy, and a Fortran programmer already understands NumPy's data model better than most Python programmers do. Two vocabulary notes: Fortran's reshape, transpose, matmul, dot_product and pack are reshape, .T, @, dot and boolean indexing.

🚨 That looseness is worth being wary of. Adding a shape (3,) to a shape (4, 1) in NumPy produces a (4, 3) array rather than an error, so a transposition mistake can quietly produce a bigger result instead of failing. The defenses are to assert shapes at function boundaries (assert values.shape == (rows, columns)) and to keep dimensions named in the code. Fortran's strictness caught these at compile time when the shapes were known statically.

The half-open convention is consistent throughout Python and worth internalizing rather than fighting: len(values[a:b]) is b - a, values[:n] and values[n:] partition without overlap, and range(n) gives exactly the valid indices. The loss that stings for scientific code is the arbitrary lower bound — Fortran's dimension(0:n) or dimension(-1:1) lets an array's indices match the physics, and neither lists nor NumPy offer it. Negative indices count from the end instead, which is a different and useful thing.

Three practical consequences. A ported loop nest should have its order flipped, or the array should be created with order="F". An array passed to scipy.linalg is copied into Fortran order if it is not already in it, so order="F" can remove a copy. And f2py handles the transposition at the boundary for you, which is one more reason the next-to-last section argues for wrapping rather than rewriting.

Two differences worth knowing for numeric work. A Python int is arbitrary precision, so integer overflow does not exist — a factorial or a large product is exact rather than wrapping, at the cost of speed. And there is no single precision at all in plain Python, so halving your memory footprint means NumPy's dtype=numpy.float32, which is where the kind parameter reappears. The type annotations shown are documentation the interpreter ignores; mypy is what reads them.

That is one of the larger quality-of-life gains in the move, and it comes with a real capability: Python strings are Unicode throughout, so accented characters and other alphabets need no special handling. The f-string is the idiom to adopt — f"value: {x:.3f}" covers most of what a format statement did, with the same kind of field specification after the colon. Strings are immutable, so building one in a loop should use a list and "".join(parts).

The idiom to adopt is the last loop: Python code iterates the values rather than an index, and reaches for enumerate(values) when it needs both. Two things a Fortran programmer will miss: there is no do concurrent, so nothing tells the implementation that iterations are independent, and there is no loop label to exit or cycle by name — a nested break leaves only the inner loop, and the usual answer is to move the inner loop into a function and return.

🚨 One match trap has no Fortran counterpart and bites everyone once: a bare name in a case is a binding, not a comparison, so case limit: matches everything and rebinds limit rather than testing against it. Compare against a literal, a dotted name (case Limits.MAXIMUM:), or use a guard as above. Where the branches are numeric rather than structural, an if/elif chain is clearer and is what most Python code uses.

🚨 intent(in), intent(out) and intent(inout) are among the most useful things Fortran gives you, and there is no Python equivalent — a function may modify any mutable argument, and the caller cannot tell without reading the body. The conventions that substitute: return a new value rather than modifying in place, name any function that mutates so it is obvious, and use a tuple or a frozen dataclass for anything that must not change. Note that Python returns multiple values as a tuple, which is more convenient than Fortran's intent(out) arguments.

🚨 One Python trap with no Fortran counterpart, and it is the classic: a default value is evaluated once, when the function is defined. So def collect(values=[]) shares one list across every call that omits the argument, and it accumulates. The rule is to use None as the default and create the mutable value inside the body. Keyword arguments are a genuine gain — a five-parameter call site becomes readable without comments.

The differences that matter in practice. A module is loaded once however many files import it, and importing it runs it, so top-level statements are executed at import time — which is why library code puts work inside functions. There is no parameter attribute, so a constant is a convention marked by an upper-case name and can be reassigned by anyone. And there is no separate compilation or .mod file to keep in step, which removes a whole class of build problems.

It is worth knowing why, since it explains what you give up. A Python wheel works everywhere because the interpreter defines the interface; a Fortran .mod file is compiler- and version-specific, so binaries cannot be shared. The counterweight is that the Python numeric stack is itself a wall of compiled dependencies, so a wheel that does not exist for your platform means building NumPy from source — a rarer problem than it was, and a memorable one when it happens. fpm is genuinely improving the Fortran side.

The f-string is the idiom and it composes better than a format statement, because the thing being formatted is an expression: f"{value * 2:.3f}" and f"{name.upper()}" both work, and there is no chance of the format list drifting out of step with the argument list. What Fortran keeps is repeat counts and complex edit descriptors for tabular output, which in Python means a loop and a width per column — or a library.

Iterating the file object reads it one line at a time, so a file larger than memory needs no special handling — which is the equivalent of the read-until-iostat loop, written as a for. Two vocabulary notes: rstrip() removes the trailing newline that read would have discarded, and a failure raises an exception (FileNotFoundError) rather than setting a status variable you have to check. For numeric data, numpy.loadtxt and numpy.save replace formatted and unformatted reads respectively.

The rule that follows: a Python loop over numbers is a bug in the design, not a slow implementation. Push the loop into NumPy, where it runs in compiled code, and the gap closes to a small factor. When no array formulation exists, the options are numba (a decorator that compiles the function), Cython, or — best of all if the Fortran already exists — f2py, which is the next section. Do not conclude from this row that Python is unsuitable; conclude that pure-Python numerics are.

This is why idiomatic Python looks the way it does. A comprehension is faster than the equivalent loop because more of the work happens inside the interpreter's C code; sum, sorted, any, all and min/max are all compiled; and a library call is compiled all the way down. The instinct to carry across from Fortran — express the whole operation at once rather than element by element — is exactly the right instinct here, for a different underlying reason.

What it reads is the intent attributes you were already writing: an intent(out) argument becomes the return value, an array dimension becomes implicit, and the wrapper handles the column-major/row-major transposition at the boundary. So the realistic plan for an existing code is not a rewrite — it is to keep the numerical kernels in Fortran, wrap them, and write the input handling, the parameter sweeps, the plotting and the analysis in Python. That is what a great deal of scientific Python actually is.

The argument for keeping the numerics is stronger than it first looks. A rewrite of working, validated numerical code buys no new capability, and its characteristic failure is not a crash but a small difference in results that nobody notices for a year — floating-point arithmetic is not associative, so even a correct rewrite may not be bit-identical. Meanwhile the things Python is genuinely better at — input handling, orchestration, plotting, testing, sharing — are exactly the parts of a scientific code that are least validated and most painful in Fortran.