GDScript.CodeCompared.To/Python

GDScript prints 3, Python prints 3.5. Python's integer division is a separate operator, //, and it floors rather than truncating — so -7 // 2 is -4 where GDScript's -7 / 2 is -3. Nothing warns you about either, which is what makes this the most expensive difference on the page.

Python prints ['coin'] then ['coin', 'gem'] — the second call inherits the first call's data. This is the single most famous Python gotcha, and a GDScript habit walks straight into it. The fix is bag=None and building the list inside.

In Python everything is a reference, so a copy has to be asked for — .copy(), or copy.deepcopy when the contents are themselves containers. The GDScript instinct that "some things copy themselves" has no equivalent to rely on.

This is the row that makes the rest of the page necessary. When so much is genuinely the same, the differences stop announcing themselves.

Python's % form takes % and a tuple, ("Robi", 1200), not a list, so the GDScript line does not port across unchanged even though it looks like it should. The f-string avoids the question entirely.

Assigning a string to something annotated float runs perfectly happily. In GDScript that same annotation is a runtime guarantee — it is the difference between a hint and a rule, wearing the same syntax.

Enums are a standard-library class rather than a language keyword, and a Python enum member prints as State.WALKING rather than its number — it keeps its name, where a GDScript enum value simply is an integer.

Python's slice syntax goes further than substr: title[-6:] takes the last six characters and title[::-1] reverses the string. Negative indices work throughout, which GDScript supports for arrays but not for string slicing.

Printing the list also works in both, though the punctuation differs: Python shows ['sword', 'shield', 'potion'] with quotes, GDScript shows its own array formatting. A row that agrees on behavior can still differ in what it prints.

A Python list also holds mixed types without complaint, exactly as an untyped GDScript Array does. What Python does not have is GDScript's Array[int] — the typed variant that is checked at runtime.

The set is the bigger gain: it brings |, & and - for union, intersection and difference, which is the reason to reach for one rather than the deduplication alone. Tuples also unpack — x, y = point — which is how Python returns several values.

The data structure is unchanged here, which is worth noticing: unlike the C#, C++ and Rust pages, there is no pressure to replace the dictionary with a typed record, because Python is as happy with string keys as GDScript is.

A missing key raises KeyError rather than returning null, so the failure surfaces where the typo is instead of several lines later when something unexpectedly holds nothing.

Python dictionaries have preserved insertion order since 3.7, so the loop is reproducible without sorting. GDScript dictionaries also preserve insertion order, which makes this one of the places the two genuinely agree.

The one thing to know is that Python is strict about mixing tabs and spaces and will refuse to run a file that does. GDScript's editor uses tabs; most Python style uses four spaces.

Neither checks that you covered every possibility, so the catch-all matters in both. Python's version arrived in 3.10 and is newer than GDScript's, which is an unusual direction for this page.

GDScript took range() from Python directly. One difference hides here: Python's range is a lazy object that generates values as needed, while GDScript's builds a real array — which matters only when the count is very large.

The same shape builds dictionaries ({k: v for ...}) and sets ({x for ...}). GDScript has map and filter that take lambdas, but nothing this compact — and comprehensions are what Python code you read will be full of.

Along with zip, which walks two collections together, this removes most reasons to write an index at all — and with them the class of bug where the index and the collection drift apart.

The annotations are checked at runtime in GDScript and ignored in Python, as the Variables section showed — the same signature carrying a guarantee on one side and a comment on the other.

The conditional expression is spelled identically in both, a if condition else b, because GDScript took that from Python too. Note True and False are capitalized, which is a small and constant source of typos.

Note the //: this is the integer-division false friend showing up in ordinary code, and using / here would have given 4.5 and a floating-point total. Unpacking also fails loudly if the count is wrong, where a mistyped dictionary key fails quietly.

self is an explicit first parameter of every method. Forgetting it is the most common early Python error, and GDScript gives you self implicitly, so there is nothing in your habits to remind you.

Python allows several parents where GDScript allows one, and calling the parent version is super().speak() in both. This is the section where the two languages are most alike.

Look at what the GDScript column is forced to do: return the unchanged balance, which cannot be told apart from a withdrawal of zero. Python stops the function, and an uncaught exception is loud rather than silent.

finally runs whether the block finished, returned, or raised, so the cleanup is written once. The with statement builds on it, which is how Python closes files without anyone remembering to.

Behind that door is the actual reason to learn Python: re for regular expressions, datetime, pathlib, csv, sqlite3 and itertools all ship with the interpreter, and pip reaches everything else. This is why the tooling around a game tends to end up written here.

The r prefix makes a raw string, so backslashes mean what they say — which is why Python regex patterns are almost always written that way. Godot's RegEx is a real engine class, so this row is a difference of ceremony rather than capability.

Whatever you build has to supply its own loop, and the frameworks people reach for (pygame, a web server, an event loop) are all answers to that one question. The GDScript column is not "better" — it is a program running inside something that already has a loop.

Eleven lines replace one keyword, and they are the eleven lines Godot is running on your behalf. Nothing here is hard — the point is that the editor cannot draw a connection between two nodes for you, because there are no nodes.

Both compute the same proportions from the same data; only the output device differs. Drawing in Python means reaching for a library — matplotlib, Pillow, pygame — and every one of them is a separate install and a separate loop, which is the practical shape of "nothing calls your code for you".