C.CodeCompared.To/Python

One line against five, and the missing pieces are each doing something in C: #include declares printf so the compiler knows its signature, main names the entry point for the linker, and return 0 sets the exit status. Python has an entry point too — the file — and an exit status, which is 0 unless you raise or call sys.exit. print also appends the newline that printf makes you write.

The f-string version cannot get the type wrong, because the value carries its type and is asked to render itself — where printf believes the format string and reads whatever bytes the specifier implies. That is the same weakness C's variadic arguments have everywhere: %d against a long reads the wrong width, and only the compiler's special-casing of printf warns you.

The two defaults are what to remember: sep=" " between arguments and end="\n" after the last one, both overridable per call. print(*range(3)) spreads a sequence into separate arguments, which is why the comma-joining loop collapses to one line. The buffering behaves exactly as C's does — line-buffered to a terminal, block-buffered to a pipe — so a program that crashes after printing can lose its last output in both languages, and flush=True is fflush(stdout). For the C-style spelling there is still sys.stdout.write, which adds nothing at all.

The output happens to match for the integer, and that is worth noticing: because integers are immutable, rebinding is indistinguishable from copying. The difference only becomes visible with a mutable object — the next rows on lists show it. The second half is the part with no C counterpart at all: sizeof(value) is a compile-time property of the storage, while type(value) is a runtime property of whatever the name currently points at.

The rule that makes this safe is worth stating exactly: the entire right-hand side is evaluated to a tuple, and only then are the names on the left bound to its parts. So a, b = b, a cannot go wrong the way a = b; b = a does, and neither can values[i], values[j] = values[j], values[i]. The same unpacking works on any iterable and nests — (name, (x, y)) = record — and first, *rest = values takes the head and keeps the tail, which is the closest Python comes to pointer arithmetic on a list.

Both extra lines print in Python and neither compiles in C. The loop variable outliving the loop is the one that surprises people most, and it is occasionally useful — after a for/else search, index tells you where you stopped. The cost is that a typo in a name is not a compile error but a NameError at run time, or worse, a silent rebinding of something that already existed.

🚨 & 0xFFFFFFFF after every operation is not an optimization, it is the semantics: leave one out and the value silently grows past 32 bits and every later result is wrong. That is the single most common way a hash or a checksum ported from C gives different answers in Python. Note also that iterating b"hello" yields integers while iterating "hello" yields one-character strings — the bytes form is what corresponds to unsigned char *. When the arithmetic really has to be fixed width, numpy.uint32 or the ctypes integer types wrap on their own.

The third line is the real difference: 2 ** 70 is exact in Python and has no C counterpart short of a bignum library. sys.maxsize is not a limit on int at all — it is the largest value a machine word holds, which matters for indexing, not arithmetic. The price is that every integer operation is a method call on a heap object, which is a large part of why numeric Python loops are slow and why NumPy exists to put fixed-width arrays back underneath them.

The last two lines disagree between the columns, and that is the lesson rather than a mistake — this is a real portability trap when translating an algorithm that uses % on negatives, such as wrapping an index around a ring buffer. Python's convention has the property that a % n is always in [0, n) for positive n, which is usually what index arithmetic wants; C's matches the hardware division instruction.

🚨 The performance consequence is the one to internalize: values[1:] inside a loop copies the whole tail every time, so a C idiom that advances a pointer becomes quadratic when it is transcribed directly. The fixes are itertools.islice, an explicit index, or memoryview for a buffer that really must not be copied. Everything else about the notation is friendlier than the pointer version: the bounds are checked, values[2:99] clamps instead of reading past the end, and a negative index counts from the far end so values[-1] is the last element.

The four to know, in order of how close they are to C. bytes is a const char *; bytearray is a char * you may write through; memoryview is a pointer into an existing buffer, so slicing one costs nothing and mutating through it mutates the original; and array.array("i", …) is a real int[] when the elements are not bytes. All four implement the buffer protocol, which is what lets ctypes, numpy and a C extension take them without copying. A plain list implements none of it, which is exactly why it cannot be handed to C.

The mixed list is the giveaway: a contiguous array of one type cannot do that, and a vector of pointers can. The consequence for a C programmer is a performance model, not just a convenience — a million-element list is a million pointers plus a million heap objects scattered across memory, where a C array is one cache-friendly block. That is exactly the gap array.array and NumPy close when it matters.

This is the most common way Python surprises a C programmer, because the aliasing has no syntax. It is the same hazard as two pointers into one buffer, minus the notation that warns you. The related trap is the mutable default argument: def add(item, into=[]) creates the list once, at definition time, and every call without an explicit second argument shares it — which is why the idiom is into=None and a fresh list inside.

🚨 The rule: decode at the edge, work in str, encode at the edge. Anything arriving from a socket, a file opened in binary mode, or a C function is bytes and must be decoded before it is text. The two failures to recognize are UnicodeDecodeError — bytes that are not valid in the encoding you claimed — and TypeError: can't concat str to bytes, which is Python refusing to guess. ctypes.c_char_p hands you bytes for exactly this reason, and sys.getdefaultencoding() is UTF-8 everywhere, so the encoding argument is usually the one you want anyway.

Strings are immutable, so line += word allocates a new string and copies everything so far — the same rescanning strcat does, without the buffer overflow. CPython has a special case that sometimes makes it linear when the string has exactly one reference, and it is an implementation detail that disappears the moment anything else holds the value. The reliable shapes are "".join(parts), an f-string when the pieces are known, and io.StringIO when they arrive over a long stretch of code. Note join is a method on the separator, which reads backwards exactly once.

C reports 2 where Python reports 5 — a zero byte terminates one and is ordinary data in the other. The deeper split is that Python's str is a sequence of Unicode code points while C's char* is bytes: len("é") is 1 in Python and strlen("é") is 2 in UTF-8. Anything crossing into C needs encode(), and bytes is the type that actually corresponds to char*.

The output makes the mechanism visible: dropping both names prints nothing, and the destructors only run when gc.collect() walks the heap and finds the pair unreachable. In ordinary code the cycle detector runs on its own and you never think about it. Two places you do: an object holding a large buffer or an operating-system handle is freed later than you expect if it is in a cycle, which is what with and weakref are for; and a __del__ is not a destructor you may rely on for cleanup, for the same reason. 🚨 It is also why Py_INCREF/Py_DECREF must balance exactly in an extension module — one extra increment leaks the object permanently, and one too few is a use-after-free that crashes somewhere else entirely.

The property they share is that cleanup runs on every path out, including the error one. What with adds is that the obligation lives in the resource rather than in every function that uses it: writing with open(name) as handle makes it impossible to forget fclose, where the goto cleanup chain has to be rebuilt correctly in each new function, in the right order, with the right guards for the partially-acquired case. contextlib.ExitStack covers the case C solves with a loop over an array of handles — a variable number of things to release.

The "freeing" line prints at a predictable moment in both columns, and that is CPython's notable property: because it counts references rather than tracing, an object dies at the statement that drops its last reference. It is why with open(...) closing promptly is reliable in CPython — though relying on it is still discouraged, since a cycle needs the backup tracing collector and other implementations do not count at all. Reference counting is also exactly what a C extension must participate in by hand, with Py_INCREF and Py_DECREF.

The rule with no exceptions: is for None, True, False and sentinel objects you created yourself; == for everything else. Which values happen to be shared is a CPython implementation detail that differs between versions and between interpreters, so code that passes its tests on integers below 257 fails on a larger one. Python 3.8 and later emit a SyntaxWarning for is against a literal, which catches most of it. sys.intern forces sharing deliberately, and is worth it only for a large number of repeated dictionary keys.

A C programmer has the advantage here, because the distinction is already familiar; the hazard is that Python's two spellings are one character apart. The classic bug is if value is 1000, which is false while if value is 5 is true — CPython caches small integers, so identity accidentally matches for them. Use is only for None, True and False, which are genuinely single objects.

A C programmer has the right instinct for this one already, because it is a static local wearing a different hat: the storage is created once and outlives the call. The default is evaluated when the def statement runs — once, at import — and stored on the function object, where you can even see it as appended.__defaults__. Immutable defaults (0, None, "", a tuple) are safe because nothing can change them, which is why None plus a check is the universal idiom. Every linter flags this, and it still ships regularly.

The asterisk means "spread" in both directions, which is the piece to get used to: in a parameter list *values collects the extra positional arguments into a tuple, and at a call site f(*values) spreads a sequence back out. ** does the same for keyword arguments and a dict. Because the tuple is a real object there is no format string to keep in step with the arguments and no undefined behavior when you promise int and pass a double — the mismatch C's va_arg cannot detect and -Wformat exists to catch.

The tuple is a real object being allocated and unpacked, so this is a convenience rather than a free abstraction — but it removes the class of bug where a function returns early having written only one of its out-parameters. divmod is worth knowing for a second reason: the hardware division instruction computes the quotient and remainder together, so asking for both at once is the operation the machine was going to perform anyway.

The dispatch table is the same design in both columns, and the difference is what a function can carry. A C function pointer is an address and nothing else, so every callback API grows a void *context parameter to smuggle state alongside it — qsort_r, every GUI toolkit, every thread entry point. A Python function closes over the variables where it was defined, so the state travels with it and no such parameter exists. functools.partial is the explicit version when a closure would be overkill.

The two things a C programmer must supply explicitly here are the ones the compiler decided silently: byte order and padding. < is little-endian, > big-endian, ! network order, and a leading = or @ asks for native — where @ also reinstates the alignment padding a C compiler would insert, which is the only mode where calcsize matches sizeof on a struct with mixed field widths. Getting this wrong is how a parser reads correctly on one machine and returns nonsense on another; writing the format string out makes it a decision rather than an assumption.

The type annotations are the part worth being clear about: x: int is not enforced at run time — passing a string works and fails later, somewhere else. They exist for readers and for external checkers like mypy. That is the opposite of C, where the declaration is the enforcement, and it is the single biggest adjustment when the compiler stops catching your mistakes.

The hierarchy is what the error code cannot do: except PortError catches both subclasses, except ValueError catches them plus anything else that means "bad value", and a caller that wants to tell the two apart still can. The failure also cannot be ignored — an unhandled exception stops the program, where an unchecked return code carries on with a garbage value, which is the single largest class of C bug this replaces. raise … from None suppresses the chained ValueError so the message says what the caller cares about, and raise … from error keeps it when the cause is worth showing.

The C column is not padded: strtol really does require clearing errno first, and really does report "not a number at all" only by leaving the end pointer where it started. What Python adds beyond brevity is that failure cannot be silently ignored — an unhandled exception stops the program with a traceback, where an unchecked C return value simply continues with a wrong number.

The flag array is faster when the range really is small and dense, and it stops working the moment the values are sparse, negative, or strings — where the C answer becomes a hash table you write yourself. A set has no such condition: membership is average constant time for anything hashable, and &, |, - and ^ are intersection, union, difference and symmetric difference. 🚨 A set is unordered, so set(values) alone loses the first-seen order the loop above preserves — dict.fromkeys(values) deduplicates and keeps it, since dictionaries have been insertion-ordered since Python 3.7.

The C version is a linear scan — correct for three entries, wrong for three thousand — and choosing when to build a real hash table is a decision Python made once for everyone. The in operator is the "found or not" question the C function answers through its return value, and ages.get(key, default) is the version that hands back a fallback instead, which is what the out-parameter was doing.

🚨 The whole difficulty of the C side is in the Py_DECREF. PySequence_GetItem returns a new reference and PyList_GetItem returns a borrowed one, and getting that distinction wrong is a leak in one direction and a crash in the other — the documentation states it per function because there is no way to tell from the signature. Two things worth knowing before starting: sum, sorted and the rest of the built-ins are already C, so the pure-Python loop is rarely the real baseline; and Cython, cffi and pybind11 all generate this layer for you, with the reference counting handled.

The argtypes/restype lines are the part people skip, and skipping them is how a 64-bit return value silently becomes 32 bits — ctypes defaults to int for anything you do not declare. The other route is a real extension module, which is faster and far more work: it means writing against Python.h, managing reference counts by hand with Py_INCREF/Py_DECREF, and deciding when to release the GIL. cffi sits between the two by parsing the actual header.