Python.CodeCompared.To/Kotlin

A Kotlin file may hold top-level functions, top-level properties and several classes, and its name need not match anything inside it. fun main() can take no parameters at all when you do not want the command-line arguments, which Java does not allow. Semicolons are optional and nobody writes them; braces do the job Python's indentation does, but the formatter and every codebase indent anyway.

A bare name needs no braces ("$name") and anything more than a name does ("${age + 1}"), which is the reverse of f-strings, where the braces are always required. There is no equivalent of print's several comma-separated arguments; println takes one value, so several values are joined with interpolation or with +. Formatting specifiers live in "%.2f".format(value) rather than inside the interpolation, so f"{price:.2f}" becomes "%.2f".format(price).

Compilation is not instant — a cold Gradle build of a real project is measured in tens of seconds — so the tight edit-run loop a Python developer relies on is replaced by an IDE that type-checks as you type and by tests you run in bulk. What you get back is that a huge class of mistake never reaches run time at all. Kotlin also compiles to JavaScript and to native binaries, but on Android and on the server it is the JVM, which means JVM startup, JVM memory, and access to every Java library ever published.

String and String? are two different types in Kotlin, and there is no way to reach a method on the nullable one without saying what should happen when it is null. That single rule removes the most common exception in the JVM world and the most common AttributeError in the Python one. The cost is that you must now be explicit at every point where absence is possible — which is the same discipline a Python developer applies by hand and by habit, moved into the compiler where it cannot be forgotten.

?. short-circuits the rest of the chain to null instead of throwing. ?: — the Elvis operator, so called because it has a quiff — supplies a value when the left side is null, and its right-hand side may be a return or a throw, which is how Kotlin spells an early guard. !! asserts non-null and throws a NullPointerException if wrong; it is a code smell, and finding one in a code review is a conversation. Python has none of these as operators — x?.y has been proposed and rejected several times — so the equivalents are conditional expressions and or, which is not the same thing because or also fires on empty strings and zero.

The same narrowing happens after a null check, so if (name != null) { name.length } compiles even though name is declared String?. Python's type checkers do exactly this analysis, which is why the pattern feels familiar — but there it is advice from a separate tool and here it is the language. One real limit: a smart cast only applies where the compiler can prove the value cannot change between the check and the use, so a mutable class property does not smart-cast, and you assign it to a local first.

A value coming back from an un-annotated Java method has a platform type, which the compiler will let you assign to either String or String? without complaint — so the null check you skipped becomes a NullPointerException at run time after all. The mitigations are real: Java libraries increasingly carry @Nullable/@NotNull annotations that Kotlin honors, and the habit is to declare the nullable type at the boundary and narrow immediately. For a Python reader the useful framing is that this is the one place Kotlin behaves the way Python always does, and it is worth knowing where those places are.

A val cannot be reassigned, which is Python's Final annotation made real and made the default choice — Kotlin style is val everywhere and var only where a loop or an accumulator needs it. What val does not mean is immutable contents: val items = mutableListOf(1) still lets you call items.add(2), exactly as a Python Final list would. Since names are declared once rather than simply assigned, a typo produces "unresolved reference" at compile time instead of a new variable holding nothing.

This is the distinction that makes Kotlin comfortable for a Python developer. You write about as few types as you do in Python, and you get the guarantee anyway. Types are written where inference cannot reach — on function parameters always, on public return types by convention — and everywhere else they are omitted. Note that integer division is integer division: 9 / 2 is 4, not 4.5, so the example writes 2.0. Python 3 made / always produce a float and left // for the truncating form; Kotlin follows Java instead.

An Int is 32 bits and a Long is 64, and overflow wraps around silently rather than raising — so a running total that exceeds two billion becomes a negative number with nothing to indicate it happened. BigInteger from the Java library is the arbitrary-precision escape hatch, and it is verbose enough that people avoid it. The division rule is the other trap: 7 / 2 is 3 because both operands are Int, matching Python's // rather than its /. Floating-point behaves identically in both, since both use IEEE 754 doubles.

Any is the top type, corresponding to object — but note it is not nullable, so a variable that may be anything including null is Any?. Unit is the type of a function that returns nothing useful and has exactly one value, printed as kotlin.Unit, which is where Python returns None. Nothing is the type with no values at all, and it is the return type of throw and of functions that never come back — which is what lets val name = maybeNull ?: throw … type-check, since a branch of type Nothing fits anywhere.

strip is trim, upper is uppercase, and join reverses into list.joinToString(", "), which reads better than ", ".join(list) once you stop expecting the separator first. The pleasant surprise is in: Kotlin lets a class define contains and then spells it in, so the membership test is written identically in both languages. Strings are immutable in both, and a Kotlin string is a sequence of UTF-16 code units rather than of code points, so a character outside the Basic Multilingual Plane counts as two.

Because it is raw, backslashes mean nothing special inside it, which makes it the natural home for regular expressions and Windows paths. Because it is still interpolating, $ is significant even there, and a literal dollar sign needs ${'$'} — the one genuinely ugly corner of Kotlin strings. Indentation is not stripped automatically the way a Python developer might hope; .trimIndent() removes the common leading whitespace and is written on essentially every multi-line literal.

== calls equals and is therefore structural, so string comparison does the obvious thing — which is worth stating explicitly because Java's == on strings compares identity and produces the single most famous beginner bug on the JVM. Kotlin fixed it by making the short operator the useful one. === is identity and corresponds to is. Ordering compares UTF-16 code units, so uppercase letters sort before all lowercase ones, exactly as in Python; a locale-aware comparison needs compareTo(other, ignoreCase = true) or a Collator.

There are no bracket literals: listOf, mutableListOf, mapOf, setOf are functions, and a map entry is written with the to infix function. List genuinely has no add method, so passing one to a function is a promise that the function will not change it — a guarantee Python offers only through tuple and frozenset. The honest caveat is that List is a read-only view, not an immutable value: hand the same underlying MutableList to two places and one can still change what the other sees. For real immutability, Kotlin teams reach for the kotlinx.collections.immutable library.

The chain reads left to right in the order the work happens, which the comprehension does not — [f(x) for x in xs if p(x)] puts the last step first. it is the implicit name for a single-parameter lambda and is used constantly. The library is large and worth browsing: associate, groupBy, partition, sumOf, maxByOrNull, zip, flatMap, chunked, windowed all exist and most have no one-line Python equivalent. Each step builds a new list; for a lazy chain over a large collection, insert .asSequence(), which is the generator-expression equivalent.

groupBy returns a Map<K, List<V>> with the types worked out for you; sumOf replaces sum(... for ...); and maxByOrNull is max(..., key=...) with the empty case handled — it returns null rather than raising, and the name says so. That naming convention runs through the whole library: a function ending in OrNull hands back null where its plain sibling throws, so the signature tells you which failure mode you are choosing.

zip matches, and produces a list of Pair objects rather than tuples. The nested comprehension for flattening becomes flatten(), or flatMap { } when a transformation happens on the way — the two-loop comprehension is one of the least readable things in Python and the named function is a clear win. chunked and its neighbor windowed (overlapping runs) have no Python counterpart short of an itertools recipe, which is worth knowing about before you write the slicing loop.

Because if is an expression, Kotlin has no conditional expression like Python's a if c else b — the ordinary if already does that job, in the reading order most people find easier. The same property lets a whole function body be a single expression after =, with the return type inferred and no return keyword, which is what classify above does. Note there is no elif: it is else if, and when the chain is about one subject you use when instead.

when comes in two forms: with a subject (when (value) { 1 -> …; in 2..9 -> …; is String -> … }) and without one, where each arm is a full boolean condition. It is an expression, so its arms return values; it smart-casts, so the is String arm can call .length; and arms may list several values separated by commas. What it cannot do is bind pieces of a structure — case [first, *_] has no equivalent, and you call .first() yourself. The next section shows the case where when is stronger than match: exhaustiveness over a sealed type.

That inclusivity is the thing to internalize: 1..5 is five numbers, where range(1, 5) is four. Kotlin also has until (1 until 5) for the Python behavior and ..< as its newer spelling, plus downTo and step as infix functions rather than as extra arguments. Ranges work on characters and on any comparable type, so if (grade in 'A'..'C') reads exactly as it sounds — and in inside a when arm is one of the tidiest things in the language.

outer@ labels the loop and break@outer leaves it, with continue@outer available too — which removes the flag variable or the extracted function that Python forces. The same labels work on lambdas: return@forEach returns from the lambda rather than from the enclosing function, and knowing that is what saves you the first time a return inside a forEach does something unexpected. Kotlin also has no for … else, which is the one Python loop feature with no counterpart here.

The differences are small. Kotlin evaluates a default expression on every call, so the mutable-default-argument bug is unreachable. Names use camelCase rather than snake_case by convention. And the trailing comma after the last parameter is legal and encouraged, which makes diffs cleaner — Python allows it too. What Kotlin lacks is **kwargs: there is no way to accept arbitrary named arguments, because the compiler has to know every parameter to check the call.

Inside the function the parameter is an Array, not a List, which is a small annoyance since arrays have a different API — numbers.toList() is the usual first line. Because Kotlin has named arguments, a parameter after the vararg is perfectly usable, which is why scale works here; positionally it would be unreachable. Only one parameter may be vararg, same as Python.

There is no Utils class holding static methods and no public static final; a top-level fun is just a function, imported as import com.example.area. const val is a compile-time constant inlined at every use site, while a plain top-level val is initialized once when the file's class is loaded — which is the closest thing to a module-level name that runs at import. Note radius * radius rather than radius ** 2: Kotlin has no exponent operator, only Math.pow.

The operator method names are ordinary words — plus, minus, times, get, contains, compareTo — marked with the operator keyword rather than wrapped in double underscores, and implementing contains is what makes in work on your own type. The infix modifier is the unfamiliar one: it lets a and b be written for a.and(b), which is where to, downTo, step and until come from — they are library functions, not syntax. The rule is to use it only where the result reads as English.

That removes the recurring Python annoyance of a lambda that grows one line too long and has to be promoted to a def. The last expression in the braces is the value, with no return. A single parameter can be left unnamed and referred to as it, which is why so much Kotlin reads as { it.name }. Function types are written (Int) -> Int, the direct equivalent of Callable[[int], int], and are checked — passing a two-parameter lambda where a one-parameter one is expected does not compile.

It is why listOf(1,2).forEach { … }, repeat(3) { … }, runBlocking { … } and every Gradle build script look like language constructs when they are ordinary function calls. If the lambda is the only argument, the parentheses disappear entirely. Python has nothing comparable — a multi-statement callback must be a named def defined above the call, which is why the same design shows up as a decorator or a context manager there instead.

Without asSequence() this example would build a million-element filtered list and then a million-element squared list to take three values from it. With it, each element flows through the whole chain one at a time and the work stops after the third — the same evaluation order a Python generator gives you. The rule of thumb matches Python's: for small collections the eager version is faster because it avoids the per-element machinery, and for large ones or early termination the lazy version wins. sequence { yield(…) } is the builder form, and is Kotlin's generator function.

::shout is a reference to a top-level function and String::uppercase is a reference to a member, which becomes a one-argument function taking the receiver — the same shape as Python's str.upper. String::length references a property and is usable anywhere a function is expected, which Python cannot do without operator.attrgetter. There is also instance::method for a reference bound to a particular object, and ::ClassName for a constructor, so names.map(::Person) works.

Both generate a readable string form, structural equality and a hash. Kotlin's copy() is dataclasses.replace and is a method rather than a module function, so it needs no import; it takes named arguments for whatever you want changed. Two differences worth holding on to: Kotlin's == calls equals and is therefore structural, with === reserved for identity — the opposite naming from Python, where == is structural and is is identity. And Kotlin generates componentN() functions, which is what makes the destructuring in the next row work.

The trap is that destructuring is positional, not by name: val (y, x) = point compiles perfectly and silently gives you the wrong values, and reordering the properties of a data class quietly breaks every destructuring of it. Python has the same hazard for tuples and avoids it for dataclasses by having no destructuring at all. The rule Kotlin teams settle on is to destructure two- or three-property types and to use property names beyond that.

There is no self parameter on methods; the receiver is this and is almost always implicit. What Kotlin calls a property is what Python's @property produces: a name that looks like a field and may be backed by a getter, so you can start with a plain val and add a get() later without changing a single caller. That is the same refactoring safety net @property gives Python, obtained without the decorator. Initialization logic that does not fit in the header goes in an init { } block.

A Kotlin class cannot be subclassed unless it is marked open or abstract, and a method cannot be overridden unless it is too — the opposite default from Python and from Java. override is then mandatory on the subclass, so a typo in a method name is a compile error rather than a method that silently never gets called, which is a real and frequent Python bug. Inheriting is written with a colon and a call to the parent constructor, and super is a keyword rather than a function. Single inheritance only; interfaces with default implementations do the mixin job.

object Registry is a class and its only instance at once — the singleton pattern with no double-checked locking to get wrong — and it is initialized lazily on first use. A companion object holds what Python puts behind @staticmethod and @classmethod, and its members are reached through the class name, so Parser.of(...) reads like a static call while actually being a method on a real object that can implement interfaces. The named-constructor pattern above, with a private constructor and a factory in the companion, is the standard Kotlin replacement for Python's several @classmethod alternative constructors.

by is delegation: class Service(logger: Logger) : Logger by logger declares that Service implements Logger and generates every forwarding method automatically, so composition costs a single line instead of one method per member. Python has no equivalent short of __getattr__ forwarding, which is dynamic, untyped and invisible to tooling. The same keyword also drives delegated properties — by lazy { } is functools.cached_property, and by Delegates.observable { } has no Python counterpart at all.

It is what monkey-patching wants to be — and note that Python cannot even attempt this on a built-in, since str.shout = … raises TypeError, so both left-hand functions have to be called the other way round. The function is resolved statically and compiles to an ordinary static method taking the receiver as its first argument, so nothing is modified, nothing global changes, and two libraries can add a shout() to String without colliding. Crucially it is scoped by import: the extension is visible only in files that import it, so its blast radius is one file rather than one process. The consequences of static resolution are worth knowing — an extension cannot be overridden by a subclass, and a real member method of the same name always wins.

An extension property has no storage; it is a getter, so it is the read-only half of @property applied from outside. The striking one is the second: fun String?.orPlaceholder() extends the nullable type, so missing.orPlaceholder() is called on a null receiver with no safe-call operator and no exception — inside the function, this is simply null. That is how toString() on a nullable value works, and how a library can offer value.orEmpty(). There is no way to express "a method that works on None" in Python.

let passes the receiver as it and returns whatever the block returns, which makes value?.let { … } the idiom for "do this only if it is not null" — the direct replacement for a Python if x is not None: block, with the advantage that it is smart-cast to the non-null type. also passes it as well but returns the receiver, so it slots into a chain without changing its value, which is what makes it the natural place for logging and assertions. The distinction between the five comes down to two questions: is the receiver it or this, and is the result the block or the receiver.

Inside the block, this is the new object, so its properties are addressed by bare name and the repeated request. prefix disappears. The block returns the receiver, so the whole thing is one expression and can be assigned, returned, or passed as an argument — which is why so many Kotlin builders and Android view-configuration blocks look this way. The nearest Python has is a constructor taking every field as a keyword argument, which works well until some of the configuration is conditional.

The when above has no else, and it compiles because the compiler can see that Success and Failure are the only possibilities. Add a third subtype and every such when in the codebase becomes a compile error pointing at the place that has not been updated. This is the thing Python genuinely cannot do: a match over a union is never checked for completeness at run time, and the missing case shows up as a function that silently returns None. It is the strongest argument for a type system that a Python reader will meet on this page.

In the Python version nothing stops a caller from ignoring the error and using port anyway, and None flows on to fail somewhere else. In the Kotlin version there is no way to reach .number without first establishing that the value is a Port. Note when (val parsed = …), which binds the subject to a name for use in the arms — a small convenience with no Python equivalent. Kotlin also ships a built-in Result<T> and a runCatching { } helper, which is the quicker route when the failure is an exception you merely want to capture.

A suspend function is called exactly like an ordinary one — no keyword, no ceremony — and the compiler enforces only that the caller is itself suspend or is inside a coroutine builder. That removes the visual noise of await from every line and makes refactoring a plain function into a suspending one a one-word change rather than a cascade through every caller. It also means you cannot tell by looking at a call whether it suspends, which some people count as a loss. runBlocking is asyncio.run: the bridge from ordinary code into coroutine code, used at the entry point and in tests and essentially nowhere else.

The real difference is underneath. Python's coroutines run on one thread, so gather gives concurrency and never parallelism, and CPU-bound work in a coroutine blocks the whole loop. Kotlin's run on a thread pool, so two coroutines can genuinely execute at the same instant on different cores — there is no GIL. That makes Dispatchers.Default a real option for CPU work where Python needs multiprocessing, and it also means shared mutable state between coroutines needs the same care as between threads.

A coroutineScope waits for every coroutine launched inside it, and if any of them fails — or if the scope body itself throws — the rest are cancelled automatically. There is no way to start a coroutine that outlives its scope by accident, which is exactly the create_task hazard where a forgotten reference produces a task that runs unobserved and swallows its own exception. Python's asyncio.TaskGroup, added in 3.11, is the same idea and is now the recommended way to write asyncio code; a reader who has adopted it will find Kotlin's version immediately familiar.

Both are cold: nothing runs until something consumes it, so ticks(3) alone does no work and collect is what starts it — the same relationship as an async generator and the async for that drives it. What Kotlin adds is the operators: map, filter, debounce, combine, flatMapLatest and dozens more, where Python would reach for a separate library. StateFlow and SharedFlow are the hot variants, and they are what an Android view model exposes to its screen.

Kotlin has no checked exceptions: no throws clause, no compiler demand that you catch anything, which is exactly Python's model and a deliberate departure from Java's. try is an expression, so it produces a value, which is why the function above is a single expression with no return; the last expression of the try or of the catch is the result, and finally does not contribute one. There is no else clause as Python has, and no exception chaining syntax — you pass the cause to the constructor instead.

require throws IllegalArgumentException and states "the caller was wrong"; check throws IllegalStateException and states "this object is not in a fit state"; requireNotNull and checkNotNull do the same and return the narrowed non-null value. The message is a lambda, so building the string costs nothing when the condition holds. Unlike Python's assert these are ordinary code and are never stripped out, so they are safe for validating real input — which assert is not, since python -O removes it.

runCatching is the bridge from exception-style code into value-style code, and Result supports map, recover, getOrNull, getOrElse and onFailure, so a pipeline of fallible steps reads as a chain instead of as nested try blocks. Python's nearest equivalent is the tuple-of-value-and-error convention, which nothing enforces. The caution worth passing on is that runCatching catches Throwable, including cancellation inside a coroutine, so coroutine code re-throws CancellationException rather than swallowing it.

Nothing runs at import time, so there are no import-time side effects, no circular-import failures, and no if __name__ == "__main__" guard — a file's top level cannot contain statements in the first place. There is no module object to hold a reference to, so import billing.invoice as invoicing becomes an alias on an individual name (import billing.Invoice as Bill). Package names should mirror directories by convention but are not required to, and Kotlin imports a handful of packages (kotlin.*, kotlin.collections.*) into every file automatically, which is why listOf needs no import.

The build file is itself written in Kotlin, which is why it reads as a sequence of trailing-lambda blocks — plugins { } and dependencies { } are function calls, not configuration syntax. Dependencies are declared per project and cached globally, so there is no environment to activate and no chance of running against the wrong one. What you pay is time and complexity: a cold build downloads a great deal and takes minutes, the Gradle daemon holds memory between builds to make later ones fast, and the failure modes are considerably harder to reason about than a pip install that went wrong. The wrapper script ./gradlew pins the Gradle version itself, which is one thing it does better than pip.

There is no assert-rewriting magic like pytest's, so failure messages come from the assertion function you chose — assertEquals, assertTrue, assertFailsWith — and the argument order is expected-then-actual, which is the reverse of what most people guess. The delightful part is the backtick-quoted function name: any string may be a test method name, so tests read as sentences. Kotest is the popular alternative with a more expressive style, and MockK is the mocking library, filling the role unittest.mock plays.