C++.CodeCompared.To/Python

A Python file is executed top to bottom the moment it is handed to the interpreter, so statements at module level run immediately — there is no entry point to declare. That also means the file is both a script and a module: importing it runs every top-level statement, which is why the if __name__ == "__main__" guard exists (see the next row). print adds the newline and flushes on a terminal, so it behaves like std::cout << … << std::endl rather than like printf.

Python compiles to bytecode, but the compiler only verifies that the source parses — names, attributes, argument counts and types are all resolved when the line executes. A typo on an error path therefore ships, and is found by the customer rather than the build. That single fact is why Python projects lean so hard on tests and on external checkers (mypy, pyright, ruff) which do statically what your compiler does for free. Budget for running them; they are not optional in the way they might look.

__name__ is a string every module carries: "__main__" when the file is the one being run, otherwise the module's own name. Without the guard, importing a module for one function also executes its demo code, its argument parsing, and anything else at top level. The rule of thumb is that a module's top level should only define things — functions, classes, constants — and anything that does something belongs under the guard or inside a function.

A Python name is a reference to an object, always — there is no value semantics anywhere in the language and no way to ask for it. second = first makes a second name for the same list, so the C++ version prints 3 4 and the Python version prints 4 4. When you do want a copy you ask: second = first.copy() or list(first) for a shallow one, copy.deepcopy(first) for a recursive one. Integers and strings appear to have value semantics only because they are immutable — there is nothing you can do through one name that another name could observe.

Functions, classes, modules and even int itself are ordinary runtime objects with attributes you can read and set. This is what makes decorators, metaclasses and monkey-patching possible, and it is why introspection in Python needs no separate reflection facility — type(), dir() and getattr() are just ordinary function calls. The cost is that essentially nothing can be resolved at compile time, which is the other half of why Python is slow (see the performance section).

Written the obvious way — def collect(value, into=[]) — this prints 1 then 2, because both calls append to the same list object created when the def ran. The None sentinel above is the standard fix and you will see it constantly. The rule is simple once you know it: never use a mutable object ([], {}, set(), or an instance) as a default. Immutable defaults — numbers, strings, None, tuples — are perfectly safe, because sharing them is unobservable.

== calls __eq__ and compares values; is compares object identity and is equivalent to comparing addresses. They coincide for interned objects — CPython caches small integers and some string literals — so a is b can be True for two separately-computed 5s and False for two separately-computed 500s, which is exactly the kind of behavior you must never rely on. Use is only for singletons, which in practice means is None, is True, is False.

Nothing prevents a name from referring to an int on one line and a str on the next, which is occasionally useful and much more often a bug the compiler would have caught for you. Note that "dynamically typed" is not "weakly typed": Python is strict about what operations a value supports, so "3" + 4 raises TypeError rather than guessing — unlike JavaScript, and unlike C's implicit conversions. The checking simply happens when the line runs.

The interpreter parses annotations, stores them in __annotations__, and otherwise ignores them entirely — so a hint that is simply wrong costs nothing at runtime and is caught only if someone runs a checker. Treat them the way you would treat a const you cannot rely on: enormously valuable for readers and for editors, worthless as a guarantee. In a codebase of any size, wire mypy or pyright into continuous integration, because that is the only thing that makes the annotations mean anything.

No overflow means no undefined behavior, no -Wsign-compare, and no need to choose a width — hashing, factorials and cryptographic arithmetic just work. The cost is that a Python int is a heap object with a sign and a digit array, so arithmetic is perhaps fifty times slower than a machine word and each value costs 28 bytes or more. When that matters the answer is not to fight it but to leave the interpreter: numpy arrays hold real fixed-width integers, and those wrap silently, which surprises people coming the other way.

This is why building a string in a loop with += is O(n²) in Python — each step copies everything so far — and why the idiom is "".join(pieces) instead, which allocates once. Immutability is what makes strings hashable, so they can be dictionary keys, and it is why passing a string to a function is always safe. Indexing yields a one-character string rather than a character type, because Python has no char: greeting[0] is "h", itself a string of length one.

Because the expression is inline there is no argument list to fall out of order with the placeholders, which is the mistake printf and std::format both still permit. The specifiers after the colon are nearly identical to C++'s — :.2f, :>10, :,, :x — since C++ adopted them. The = suffix is a debugging convenience with no C++ counterpart: f"{value = }" prints both the expression source and its result.

A str is indexed by code point, so len counts characters and greeting[2] is "ï" rather than half of it. Bytes come from .encode() and go back with .decode(), and every I/O boundary is one of those two — which is why Python 3 forced the migration that broke so much Python 2 code. The discipline it imposes is worth importing back into C++: decide at each boundary whether you hold text or bytes, and never let a function be vague about which.

The array holds pointers, not values, so a list of a million integers is a million pointers plus a million separate heap objects — perhaps 20 times the memory of a std::vector<int>, with none of the cache locality. That is the price of heterogeneity, and when it matters the answer is array.array or a numpy array, both of which store values inline. Negative indexing has no C++ equivalent and is genuinely handy: readings[-1] is the last element, and slicing (readings[1:3]) makes a new list rather than a view.

Insertion order is guaranteed, which makes dict useful for things std::unordered_map cannot do (round-tripping JSON, ordered configuration) and means output is reproducible across runs. There is no sorted-map equivalent; when you need key order you write sorted(stock.items()). Note the two lookup styles: stock["missing"] raises KeyError — matching .at(), not operator[], since Python never inserts on read — while .get(key, default) is the non-raising form. collections.defaultdict is the one that does insert.

A C++ ranges pipeline reads left to right in execution order; a comprehension puts the result expression first and the source and condition after, which takes a few days to feel natural. Square brackets build a list eagerly; swapping them for parentheses gives a generator expression, which is lazy exactly like a view and is the right choice when the result is only iterated once. Dict and set comprehensions use braces: {name: len(name) for name in words}.

Unpacking is plain assignment, so it works anywhere assignment does: in a for target (for name, count in stock.items()), in function parameters, and in the swap idiom above, which needs no temporary because the right-hand side is fully evaluated first. The starred form has no C++ equivalent and is genuinely useful for splitting a head from a tail. Note // for integer division: plain / always produces a float in Python 3, so 17 / 5 is 3.4, which is a real difference from C++ integer division.

Because there is no second mechanism, the visual structure and the actual structure are the same thing — the class of bug where a statement looks like it is inside an if and is not simply cannot occur. The rules to know: four spaces is the near-universal convention (PEP 8), tabs and spaces must not be mixed, and a block cannot be empty — use pass where C++ would use {}. Line continuation inside brackets is implicit, so a long call may span lines without a backslash.

Falsy values are: False, None, zero of any numeric type, and every empty container or string. Everything else is truthy, including "0", "False" and [0]. The idiom if not readings is preferred over if len(readings) == 0. The trap to watch for is that if value: and if value is not None: differ whenever 0 or "" is a legitimate value — which is exactly when a function returns a count or a name that might be empty.

The patterns can test type (int()), bind names (as number), destructure sequences ([first, *rest]) and mappings ({"kind": kind}), and nest arbitrarily — which covers the ground std::visit, if constexpr and structured bindings share between them in C++. Two warnings: it is not exhaustiveness-checked, so a missing case silently falls through to nothing without a case _, and a bare name in a pattern always binds rather than compares, so case SOME_CONSTANT: does not do what it appears to.

Any parameter can be passed by name, so the call site documents itself and argument order stops mattering. The bare * is the part worth adopting deliberately: every parameter after it must be passed by keyword, which makes the boolean-trap call connect(host, port, True, False) a TypeError rather than a puzzle. C++ has no equivalent — the nearest approximations are a strongly-typed options struct or designated initializers, both of which cost more and give less.

*values collects surplus positional arguments into a tuple and **options collects surplus keyword arguments into a dict; the same two sigils unpack at a call site, so report(*arguments) spreads a list into separate parameters. This is how decorators forward arbitrary calls, and how wrapper functions stay agnostic about what they wrap. The trade against variadic templates is the familiar one: no compile-time type checking, no monomorphization, and the packing costs a real tuple and dict at every call.

@announced above is exactly square = announced(square), which is why no call site changes. This is only possible because functions are ordinary objects that can be passed around and rebound, and it is the mechanism behind most Python framework magic you will meet — @property, @staticmethod, @functools.cache, Flask's @app.route, pytest's fixtures. @functools.wraps copies the name and docstring onto the wrapper, without which introspection and tracebacks report the wrapper instead of the real function.

self is the receiver written out — the same hidden parameter C++ calls this, made visible and required in every method signature. Access control, meanwhile, does not exist: a single leading underscore is a convention meaning "not part of the interface", and a double underscore only mangles the name rather than protecting it. Python's position is that the author of the calling code is an adult who may need the escape hatch. The compensating feature is @property, which lets a plain attribute become a computed one later without changing any caller — so the C++ habit of writing a getter for every field up front is unnecessary here.

The @dataclass decorator reads the class's annotations and generates __init__, __repr__ and __eq__ — the constructor, the stream operator and operator==, in C++ terms. Options extend it: frozen=True makes instances immutable and hashable, order=True adds the comparison operators, slots=True drops the per-instance dict for a real memory saving. Note that the annotations are load-bearing here in a way they usually are not — the dataclass machinery reads them at runtime even though the interpreter still does not check them.

The double-underscore names — "dunder" methods — are the protocol the interpreter calls: __add__ for +, __eq__ for ==, but also __len__ for len(), __iter__ for for, __getitem__ for indexing and slicing, __enter__/__exit__ for with, and __call__ to make an instance callable. That means built-in functions and statements are customizable, not just operators. What Python does not let you overload is assignment (there is nothing to overload — see the object-model section) and, notably, and/or/not.

Both accept any type that structurally supports the operations used, and neither requires a common base class — a C++ template and a Python function are equally happy with unrelated types. The difference is purely when the check happens: instantiation time for the template, call time for Python. So the template produces a compile error and specialized machine code, while Python produces an AttributeError at the moment the bad call is reached and one generic implementation. C++20 concepts are the constrained version; the next row is Python's.

Dog satisfies Speaking without inheriting from it or registering anywhere — the match is structural, exactly as with a C++ concept. What differs is where the check lands: mypy or pyright verifies it, so a violation is a lint failure rather than a compile error. @runtime_checkable buys back an isinstance test, with a caveat worth knowing — it checks only that the method names exist, never their signatures, so a speak taking three arguments passes. Python's other interface mechanism, abc.ABC, is nominal instead — a class must explicitly inherit from it — which makes it the analogue of an abstract base class rather than of a concept.

CPython refcounts, so an object is usually collected the moment its last reference goes away, and __del__ usually runs promptly. Usually. A reference cycle defers it to the cycle collector, an exception traceback holds frames alive, and interpreter shutdown may skip it entirely — and other implementations such as PyPy do not refcount at all. So __del__ is a last-resort safety net, never a cleanup mechanism. The construct that does give C++-style deterministic cleanup is with, in the next row.

The guarantee is genuinely comparable: the exit code runs whether the block finishes normally, returns, or raises. The difference is that it is tied to a block rather than to an object, so it does not compose through data members the way a C++ destructor does — an object owning three resources cannot simply hold three members and let the compiler sort it out; it must manage them itself or be used inside a with. This is why with open(...) as file: is the only correct way to open a file in Python, and why contextlib.ExitStack exists for the dynamic case.

Python programs use exceptions where C++ would check first, a style with the acronym EAFP — easier to ask forgiveness than permission. It is not merely tolerated but expected: iteration ends by raising StopIteration, and attribute lookup failing raises rather than returning a sentinel. Two clauses have no C++ counterpart: else runs when the try body raised nothing, which keeps the protected region narrow, and finally runs regardless — the closest thing to a destructor guarantee outside with. Catch specific types, never bare except:, which also swallows KeyboardInterrupt.

Every exception derives from BaseException, and everything you would normally catch derives from Exception, so except Exception genuinely covers the error cases while still letting KeyboardInterrupt and SystemExit through. C++ has no such guarantee: throw 42 is legal, so catch (const std::exception&) can miss things and catch (...) gives you no object. Note as problem binds the exception, that the class body here is just a docstring, and that re-raising is a bare raise which preserves the original traceback.

A type becomes iterable by defining __iter__ (returning an iterator) and the iterator defines __next__ (returning the next value or raising StopIteration). There is no notion of a position, so there is no random access, no reverse iteration, no iterator arithmetic and no way to compare two iterators — but also no iterator invalidation to reason about and no way to construct a mismatched pair. This single-object design is what makes an infinite sequence expressible, which is what the next row is about.

Reaching a yield hands a value to the caller and freezes the frame — locals, instruction pointer and all — until the next value is requested. That is what lets fibonacci be an infinite loop and still terminate: it produces one value per request and nothing is precomputed. Memory is O(1) rather than O(n), which is the usual reason to reach for one. C++23's std::generator is the direct equivalent and arrived roughly twenty years later. Note the tuple assignment doing the two-variable update with no temporary.

A module is executed exactly once, the first time anything imports it, and thereafter every import is a lookup in sys.modules — so there is no textual duplication, no include guard, and no combinatorial recompilation. Two consequences to plan for: because import executes the module, top-level side effects run at import time, and because modules are cached, circular imports fail in confusing partially-initialized ways rather than looping forever. Prefer from module import name over from module import *, which pollutes the namespace unpredictably.

The rule to internalize is that a virtual environment is not optional — installing into the system Python breaks the system's own tools, and recent Python releases actively refuse it. Every project gets its own .venv, which is the isolation a C++ toolchain gives you by accident when each project has its own build directory. The modern packaging file is pyproject.toml, and faster front-ends such as uv and poetry are widely used, but they all install into the same per-project directory.

Every operation goes through the interpreter loop, every intermediate value is a heap-allocated object, and every method is looked up by name at call time — none of which can be optimized away, because any of them could be replaced at runtime. The practical consequence is not "avoid Python" but "do not write the inner loop in Python": sum(range(...)) above runs the whole loop in C. This is the pattern behind numpy, pandas and every scientific library — Python orchestrates, compiled code iterates.

The Global Interpreter Lock means a standard CPython process executes bytecode on one thread at a time, so threading gives you concurrency without CPU parallelism. That is still useful — the lock is released around blocking I/O and around compiled extension work, so a threaded network client or a numpy workload does scale — but four CPU-bound Python threads do not go four times faster. The answers are multiprocessing, which pays a serialization cost to get separate interpreters, or the free-threaded build from PEP 703, optional since 3.13 and still stabilizing.

The options in rough order of adoption are pybind11 (header-only, modern C++, the common choice), nanobind (its faster successor), Cython (compile annotated Python), and ctypes/cffi (call an existing shared library with no build step). All of them share the design rule above: a call across the boundary costs around a microsecond, so a function called once with a million-element array is free and the same function called a million times on one element is a disaster. Design the interface around bulk operations, which is exactly why numpy looks the way it does.