Lua.CodeCompared.To/Python

The separator is the first tiny difference: Lua's print puts a tab between arguments and Python's puts a space. Python also lets you change it — print(a, b, sep="") — which Lua has no equivalent for.

The practical effect is that a misplaced line does not fail to parse — it silently belongs to a different block. There is no end to line up against, so the indentation is the only record of what you meant. Four spaces is the universal convention, and mixing tabs with spaces is an error.

Python has no true block comment. A triple-quoted string is the convention, and in the first position of a module, class or function it becomes the docstring — readable at run time through __doc__ and by help(), which Lua has no counterpart to.

Writing true in Python is not a syntax error — it is a name lookup, so it fails at run time with NameError: name 'true' is not defined. The error names the mistake clearly, which is more than most such slips manage.

That is the safer default, and it removes Lua's most notorious footgun outright. The keywords that opt out are global and nonlocal, and they are rare enough in real code that most Python programmers seldom write them.

Without nonlocal this raises UnboundLocalError rather than silently doing nothing, because count += 1 reads before it writes. That is a mercy — the closest GDScript equivalent fails silently — but it is still the single most common surprise for someone carrying Lua closure habits over.

A name assigned anywhere in a function is visible everywhere in that function, including before the line that assigned it (where it raises rather than reading as absent). A loop variable also outlives its loop, which is occasionally useful and more often a surprise.

Python's version is tuple unpacking rather than a special assignment form, so it works on any iterable, nests ((a, b), c = (1, 2), 3), and supports a starred name that collects the rest. Lua's multiple assignment does none of those.

Final is a hint for a static type checker such as mypy; the interpreter itself ignores it entirely and the assignment still succeeds. Lua 5.4 added a genuine <const> attribute, but Fengari implements 5.3, so this page cannot show it.

So if count then in Lua passes for a count of zero and if count: in Python does not. Every guard written around a number or a collection changes meaning in the port, silently. Where you mean "was it supplied", test is not None explicitly.

The idiomatic comparison is is None rather than == None, because is tests identity and cannot be intercepted by a class's __eq__. Unlike nil, None is a real object with a type, so it can be stored in a list or a dict value without disappearing.

The three safe forms are get(key), get(key, default) and an in test. This is the most common crash when carrying Lua habits over, and the same trap appears on /lua/gdscript for the same reason.

del is the removal statement, and pop(key, default) removes and returns in one step without raising when the key is absent. Carrying the Lua habit over produces a dict whose len never goes down.

Python has a real default parameter, applied when the argument is genuinely absent, which is the right tool. When you do need a fallback expression, test is not None rather than relying on truthiness.

Both also floor toward negative infinity rather than truncating toward zero, so -7 // 2 is -4 in both. C, GDScript and JavaScript each get this differently, and the C and GDScript pages have a gotcha row about it — this page does not need one.

There is no math.maxinteger because there is no maximum. The cost is that large-integer arithmetic gets slower rather than wrong, which is almost always the better trade — and it removes a whole class of bug that the C page has to warn about. 🚨 Fengari, which runs the Lua column in your browser, uses 32-bit integers, so clicking run here prints 2147483647 rather than the 64-bit maximum a desktop lua reports. The language specifies 64-bit integers; this build does not provide them.

The Python-specific oddity is that bool inherits from int, so True == 1 and True + True == 2. Lua keeps booleans strictly separate, and mixing them into arithmetic is an error there.

That refusal is deliberate and generally welcome — it catches the mistake at the point it happens. The one operator that does something surprising is *, which repeats a string rather than raising, so "10" * 3 is not thirty. One browser caveat: Lua 5.3 makes string-to-number coercion produce a float, so Fengari prints 15.0 where a 5.4-or-later desktop lua prints 15. The coercion happens either way; only the subtype differs.

An f-string interpolates any expression and can carry a format spec — f"{value:.2f}" — so it covers what string.format does while staying readable. The % operator is the older form and maps almost exactly onto Lua's string.format.

Lua's sub(2, 3) becomes [1:3]. Both languages accept negative indices counting from the end, which is one convenience they genuinely share. Python slices also take a step — text[::-1] reverses a string — which Lua has nothing like.

The method-call syntax matches too. Lua reaches string methods through the string metatable's __index; Python through the str type. The practical consequence is the same in both — building a string in a loop is quadratic, so collect the pieces and join them once.

Note which side the separator is on: "|".join(parts) puts it on the string and the sequence in the argument, the opposite of table.concat(parts, "|"). It is the single most commonly written-backwards line for a Lua programmer.

The character classes translate — %a to [a-z], %s to \s, %d to \d — with the percent sign becoming a backslash. Alternation, grouping and lookaround have no Lua equivalent at all. Note also that many jobs need no regex here: split, startswith and in cover most of it.

Python 3 separates the two into str (code points) and bytes, and refuses to mix them without an explicit encode or decode. That separation is why len is always the answer you meant, and why file and network code has to say which it is dealing with.

The two with no Lua counterpart are worth learning early. A tuple is immutable, which is what lets it be a dict key or a set member. A set gives O(1) membership testing and real union, intersection and difference operators — all of which Lua makes you build out of a table with true values.

Unlike Lua, reading past the end raises an IndexError rather than giving nil, so an off-by-one fails loudly. enumerate(values, start=1) will even count from 1 if you want to keep the Lua numbering while reading the list.

Iterating a dict directly yields its keys, matching Lua's pairs when you ignore the value. One real difference: Python dicts preserve insertion order and have since 3.7, where Lua's pairs order is explicitly unspecified and can vary between runs.

sort mutates in place and returns None, which catches people who write values = values.sort(); sorted(values) is the version that returns a new list. Lua's table.sort also mutates in place, so that half is familiar.

Comprehensions exist for lists, dicts, sets and generators, and they are the most characteristically Python thing on this page. They are also the feature most worth learning early: a great deal of Python reads as one, and the equivalent Lua loop is four lines every time.

A Lua table can key on any value including another table, compared by identity. Python requires the key to be hashable, so lists and dicts are rejected and tuples are accepted. That is why a coordinate pair is written (3, 4) rather than [3, 4] when it is used as a key.

Both shallow copies leave nested collections shared. Python has copy.deepcopy in the standard library for the real thing; Lua has no built-in deep copy at all and every project writes one.

Python also chains comparisons the way mathematics does — if 70 <= score < 90: is one expression, not two joined by and. Lua has no equivalent and needs the explicit conjunction.

A single argument, range(5), counts 0 through 4, which pairs with zero-based indexing and is the form written most. range is also a lazy object rather than a list, so range(10 ** 9) costs nothing until iterated.

Python has the keyword, and compound assignment (countdown -= 1) which Lua lacks entirely. Note print(value, end=" ") as the counterpart of io.write — it suppresses the newline rather than writing raw.

The translation moves the test to the bottom as a break, and keeps Lua's sense — it stops when the condition becomes true — rather than inverting it. Python also allows an else on a loop, which runs when the loop finished without breaking; Lua has nothing like it.

match is more than a switch: it destructures sequences and mappings, binds names, and matches on class shape with case Point(x=0, y=y). There is no fall-through, so no break is needed. Lua has no equivalent at any level.

Python's anonymous form, lambda, is limited to a single expression — no statements, no multi-line body — so it is far less capable than Lua's anonymous function. Where Lua would use an inline function, Python usually names one with def.

The difference shows when you do not unpack: Lua's extra values are discarded, while Python hands you the tuple itself. That is usually an advantage — the result can be stored, passed on, or used as a dict key.

**options has no Lua counterpart at all: it collects keyword arguments into a dict. Lua approximates named arguments by passing a single options table, which is the same idea implemented by hand — and Python supports that style too.

Python also checks the argument count: too few or too many is a TypeError, where Lua silently passes nil or discards the extras. And any parameter can be passed by name, which makes a long call readable without an options table.

The asymmetry is assignment, not reading — as the nonlocal row showed. Compare GDScript, which captures by value and silently does nothing; Python at least refuses to run rather than misbehaving.

The @ syntax is sugar for greet = with_logging(greet), so a Lua programmer already understands the mechanism. What the syntax buys is that the wrapping is declared at the definition rather than somewhere below it, which is why decorators show up everywhere in Python frameworks.

Counter.__index = Counter is what a Python class already is, setmetatable is what calling the class does, and __init__ is Counter.new. The mechanism is the same lookup-fallback idea; Python simply names the parts.

So greeter.greet() and Greeter.greet(greeter) are the same call in Python, exactly as greeter:greet() and Greeter.greet(greeter) are in Lua. A Lua programmer already understands why self is there; Python just removes the colon-versus-dot choice by always requiring it.

The Lua version needs two setmetatable calls and an __index at each level, and getting one wrong yields a silent nil. Python's parenthesized base does the wiring, and super().speak() reaches the parent — which in Lua means Animal.speak(self). Python also supports multiple inheritance, which Lua can only approximate with an __index function.

A @dataclass generates __init__, __eq__ and __repr__ from the annotated fields. It is a decorator, so it is the previous section's mechanism applied to a class — nothing new, just a very good use of it.

A single leading underscore means "internal, do not touch" and is enforced by nothing. A double underscore triggers name mangling, which makes accidental collision unlikely but is still not privacy. The Lua closure approach is genuinely stronger — at the cost of one closure per instance.

This is the first of many one-to-one correspondences between metamethods and dunder methods, which the next section takes up properly. It is the reason Python's object model feels immediately legible to a Lua programmer.

The parallel to rawget is instance.__dict__, which reads the instance's own attributes without triggering any fallback. Note __getattr__ fires only after normal lookup fails, which is __index's behavior exactly; __getattribute__ intercepts every access and has no Lua equivalent.

One difference matters: __newindex fires only for keys the table does not already have, while __setattr__ fires for every assignment. That is why the constructor has to go around it with object.__setattr__ to set the initial value at all.

The mapping is __add→__add__, __sub→__sub__, __eq→__eq__, __lt→__lt__, __len→__len__, __call→__call__, __tostring→__str__. Compare JavaScript and GDScript, neither of which can overload an operator at all.

The extra consequence in Python is worth knowing: with no __bool__ defined, __len__ decides truthiness, so an object of length zero is falsy. That is the truthiness rule from earlier reaching all the way into your own classes — and it has no Lua parallel, since a Lua table is always truthy.

The neat part is that __iter__ can be a generator — the yield keyword — so you write the loop directly rather than manufacturing a closure over mutable state. Ending is explicit too: a generator returning is the signal, where Lua overloads nil.

Because pcall returns rather than branching, Lua code checks a boolean where Python code nests a block. Python also has else (ran without raising) and finally (always runs) — the latter having no real Lua equivalent before 5.4's <close>, which Fengari does not implement.

Python selects the handler by exception class, so unrelated failures are not swallowed by a handler meant for something else. That is the practical difference: pcall is all-or-nothing, and a bare except Exception is the Python equivalent that experienced code avoids.

Python's assert is a statement removed entirely when the interpreter runs with -O, so it must never validate input that could legitimately be wrong. Lua's is an ordinary function that is always present, and is therefore safe in shipping code — the reverse of the usual expectation.

A with block calls __exit__ however the block ends — normally, by exception, or by return — which is what makes with open(path) as file the universal Python idiom. Lua 5.4's <close> attribute is the closest equivalent, and Fengari does not implement it.

Two differences in the wrapping. Any function containing yield is automatically a generator — there is no coroutine.create — and calling it returns the generator object without running any of the body. next() is coroutine.resume, and exhaustion raises StopIteration rather than returning false.

Python splits resumption into next() (send nothing) and send(value), where Lua uses coroutine.resume for both. The first resume must be next() or send(None), because there is no suspended yield waiting to receive a value yet — the same rule Lua has, where the first resume's extra arguments become the function's parameters instead.

So both use a suspendable function to drive a loop, and Python needs no wrapper. The termination signal differs: Lua's loop stops on nil, which means a genuine nil in your data ends the loop early; Python raises StopIteration, so None is a perfectly valid value to yield.

Python's generator expression is a comprehension that produces values on demand, and the whole itertools module is built to consume them. That makes an infinite sequence an ordinary tool rather than a curiosity, which is a genuinely different way of writing loops.

require is an ordinary function, so a Lua module path can be computed at run time; import is a statement, which is what lets tooling see the dependency graph. Python also has importlib.import_module for the dynamic case.

That makes the Lua version explicit about its interface and the Python version explicit about nothing — the convention is a leading underscore for internals, and __all__ to declare what from module import * exports. The __name__ == "__main__" test is Python's way of writing a file that is both importable and runnable.

The difference in philosophy is the whole story of this page compressed into one row. Lua expects the host or LuaRocks to supply what you need; Python expects it to be there already. Neither is wrong, but it changes what "write a script" means.

In Lua the guard is meaningless — #items is a number and every number is truthy. In Python it is the idiomatic emptiness test, usually written as if not items: without the len at all.

A default expression is evaluated once, when the def executes, so a mutable default is shared by every call that omits the argument. The fix is always the same: default to None and build the real value inside. Note this is exactly the shape a Lua programmer reaches for first.

So the Lua habit of "== means same table" translates to is, not ==. Using is for numbers or strings appears to work because of interning and then fails on larger values, which is why it is reserved for None, True and False.

A list is a contiguous sequence and cannot grow by assignment to an arbitrary index; append is the only way to extend it. When the keys really are sparse integers, a dict is the correct structure and behaves the way the Lua table did.

Reusing a common name like value or index as a loop variable therefore clobbers whatever was there. Comprehensions are the exception: their variable is scoped to the comprehension and does not leak, which is one more reason to prefer them.