Your JavaScript runs on one thread, but the waiting doesn’t. Node hands network I/O to the operating system (epoll, kqueue, IOCP) and file-system work to libuv’s thread pool, then runs your callback on the main thread when the result is ready. The main thread never waits; it only runs callbacks.

A loop inside libuv that cycles through phases: timers, pending callbacks, poll (I/O), check (setImmediate) and close callbacks. Each phase has a queue, and each callback runs to completion on the call stack before the next one starts.

Synchronous code first. Then the whole nextTick queue, then the whole promise microtask queue. Only then does the loop move on to setTimeout callbacks in the timers phase and setImmediate in the check phase. Both microtask queues are drained again after every single callback.

Node starts an ES module from inside a promise job, so when its top-level code finishes, V8 is still draining the microtask queue and runs the promise callbacks you queued before Node gets to the nextTick queue. In CommonJS the nextTick queue goes first. The examples on this line are CommonJS: run scenario 1 as an .mjs file and C and D swap places.

From the main module it isn’t guaranteed; it depends on how quickly the loop starts. Inside an I/O callback, setImmediate always wins, because the check phase comes straight after the poll phase.

It runs work that has no non-blocking OS API: most fs calls, dns.lookup, and CPU-heavy crypto and zlib functions. It has 4 threads by default, set by UV_THREADPOOL_SIZE. Network sockets don’t use it.

Any long synchronous work: a huge JSON.parse, sync fs or crypto calls, heavy loops, a regex with catastrophic backtracking. While it runs, no request, timer or promise can move. Split the work into chunks, stream the data, or move it to worker_threads.

A timer’s delay is a minimum, not a promise. The callback runs in the first timers phase after the delay has passed, so a long callback ahead of it delays it, exactly like the loop done at 100 ms scenario on this line.

Yes. The nextTick queue is drained completely before the loop continues, so a callback that keeps scheduling another nextTick stops all I/O. setImmediate yields to I/O instead.

worker_threads run JavaScript in parallel inside one process and can share memory with SharedArrayBuffer; use them for CPU-heavy tasks. cluster, or several processes behind a load balancer, runs separate Node processes so a server can use every core.

Macrotasks are the callbacks the loop picks up phase by phase: timers, I/O callbacks, setImmediate, close events. Microtasks are promise reactions and queueMicrotask callbacks, plus Node’s own nextTick queue. After every single macrotask callback, Node drains both microtask queues completely before it runs the next one.

queueMicrotask puts a callback on V8’s microtask queue, the same queue promise callbacks use. process.nextTick uses a separate Node queue that, in CommonJS, runs before it. Prefer queueMicrotask: it works the same in browsers and Node, and it can’t jump ahead of promises you already queued.

The loop asks the OS for finished I/O and runs those callbacks. If there is nothing to run, it waits there for new I/O, but only until the nearest timer is due. If a setImmediate is queued, it doesn’t wait at all and moves straight on to the check phase.

An async function runs synchronously up to its first await. There it returns a pending promise to its caller, and the rest of the function is resumed later as a microtask once the awaited value settles. Nothing runs in parallel: await just splits your function into callbacks.

Since Node 15, an unhandled rejection emits unhandledRejection, and if nothing handles it, it is thrown as an uncaught exception and the process exits with an error. In an uncaughtException handler, log and exit: the process is in an unknown state, so let a supervisor restart it instead of carrying on.

No. The promise, callback and sync versions of fs do the same work; the async ones run it on libuv’s thread pool and only differ in how you get the result. Network I/O, including fetch and http, is the part that goes to the OS without the pool.

dns.lookup, which http and net use by default, calls getaddrinfo on the thread pool. With only 4 threads, a few slow lookups can occupy the whole pool and fs, crypto and zlib work queues up behind them. Raise UV_THREADPOOL_SIZE, cache lookups, or use dns.resolve, which queries the network directly.

Streams move data in chunks instead of loading it all at once, so a 10 GB file uses the same memory as a 10 KB one, and processing starts with the first chunk. There are four kinds: Readable, Writable, Duplex (both, like a socket) and Transform (a Duplex that changes the data, like gzip).

It is what happens when the producer is faster than the consumer. write() returns false once the internal buffer passes highWaterMark, and you should stop writing until 'drain'. Ignore it and the buffer grows until the process runs out of memory. pipe() and pipeline() handle it for you.

.pipe() doesn’t forward errors: if one stream fails, the others stay open and leak file descriptors or sockets. pipeline() destroys every stream when any of them fails and gives you one callback, or one promise from stream/promises, for success or error.

No. emit() calls every listener synchronously, in the order they were added, on the current call stack, and returns only when all of them have finished. A slow listener blocks the emitter. And an 'error' event with no listener throws.

Measure the delay: perf_hooks.monitorEventLoopDelay() gives a histogram of how late the loop is, and performance.eventLoopUtilization() shows how busy it is. To find the cause, take a CPU profile with --cpu-prof or the inspector and look for long synchronous frames in the flame graph.

setInterval fires on schedule whether or not the previous async run has finished, so slow requests overlap and pile up. Scheduling the next setTimeout at the end of each run guarantees a gap between runs and makes back-off easy.

Each worker has its own V8 isolate and event loop, so nothing is shared by default. postMessage copies data with the structured clone algorithm; listing an ArrayBuffer as transferable moves it instead of copying. Only a SharedArrayBuffer is truly shared, and you coordinate access to it with Atomics.

spawn starts a program and streams its output. exec runs a command through a shell and buffers the output, so it’s open to shell injection and limited by maxBuffer. execFile is exec without the shell. fork starts another Node process with an IPC channel for send() and 'message'.

On SIGTERM, call server.close() to stop accepting connections and let in-flight requests finish; close idle keep-alive connections (closeIdleConnections()); then close database pools and queues, and exit. Add a hard timeout so a stuck request can’t hold the process forever.

It carries context, such as a request ID or the current user, through every callback and await that follows from a request, without passing it as an argument. It is the async equivalent of thread-local storage, and it is how loggers and tracing tools tag everything done for one request.

With an AbortController. Pass its signal to fetch, fs.readFile, the promise versions of the timers, events.once or your own functions, then call abort(). AbortSignal.timeout(ms) gives you a signal that aborts on its own.

The loop keeps running while anything still holds it open: a timer, an open socket or server, a database pool, a child process. Close what you opened. For a handle that shouldn’t keep the process alive on its own, such as a background interval, call .unref().

It runs nothing: the operations started when you created the promises, and Promise.all only waits for them. They wait concurrently, and it rejects as soon as one rejects, without cancelling the others. Use allSettled to get every result, any for the first success, race for the first to settle, and a limiter such as p-limit when you have thousands of tasks.

One list object is created on the heap and both names refer to it. Assignment never copies: it binds a name to an object, and the list’s reference count goes to 2.

Neither. It passes references to objects by value, often called call by sharing. A function can mutate an object you pass in and you’ll see the change, but rebinding the parameter inside the function doesn’t touch your variable.

Mainly by reference counting: when an object’s count drops to zero it’s freed immediately. A generational cyclic garbage collector finds groups of objects that only reference each other, which refcounting alone can never free.

is checks identity: are these the same object? == checks equality through __eq__. Use is for singletons like None, and == for everything else.

CPython caches the integers from -5 to 256, so those are always the same objects. Whether other equal numbers or strings share an object depends on interning and constant folding, an implementation detail you should never rely on.

Not directly. del removes a name (or a container item) and decrements the reference count. The object is freed only when its count reaches zero, or later by the garbage collector if it’s part of a cycle.

Small objects come from pymalloc, which takes memory from the OS in large arenas and can only give an arena back when every block in it is free. A few surviving objects keep whole arenas alive, as the pymalloc demo on this line shows. Python reuses that memory; it just doesn’t hand it back.

Look for references that live too long: module-level caches, an unbounded functools.lru_cache, closures and callbacks that capture big objects, and globals. tracemalloc shows which lines allocated the memory that stays, and gc.get_referrers() shows who is holding an object.

For caches and back-references that shouldn’t keep an object alive. A weak reference doesn’t increase the reference count, so the object can still be freed, after which the weak reference returns None.

Every CPython object has a counter of how many references point at it: names, list slots, dict values, attributes. Binding a name adds one, dropping it subtracts one, and at zero the object is freed immediately. sys.getrefcount(x) shows it, one higher than you expect because the call itself holds a reference.

Since Python 3.12 (PEP 683), objects such as None, True, False, small ints and many interned strings have a fixed reference count that never changes and are never freed. Skipping those counter writes saves work, keeps memory pages shared after fork, and makes sharing them between threads and interpreters safe.

Reference counting can’t free cycles. If a list contains itself, or two objects point at each other, their counts never reach zero even when nothing else can reach them. The cycle collector finds such groups by subtracting the references they hold to each other and frees the ones left with no outside references.

The collector sorts container objects by age. New objects start in the youngest generation, which is scanned often because most objects die young; survivors are promoted to older generations that are scanned less and less often. Thresholds from gc.get_threshold() decide when each one runs.

Rarely. Reference counting frees almost everything, and the collector already runs on its own. Disabling it is safe only if your code never creates cycles, otherwise those leak. The one common tuning is gc.freeze() before forking workers, so the collector doesn’t touch, and copy, pages the children share.

It’s a finalizer that runs when an object is about to be freed. When that happens depends on reference counts, cycles and the Python implementation, so it’s a bad place for closing files or connections, and exceptions raised in it are only printed. Use a context manager (with) or weakref.finalize instead.

CPython’s allocator for small objects, 512 bytes or less. It takes big arenas from the OS, splits them into pools, and each pool hands out blocks of one size class. Creating and freeing small objects then costs almost nothing, because most requests never reach the system allocator.

It only measures the object itself. For a list that is the header plus the array of pointers, not the objects they point at. A list of a thousand strings reports a few kilobytes however long the strings are. To measure the whole structure, walk it, or compare tracemalloc snapshots before and after.

It replaces the per-instance __dict__ with fixed slots in the object itself. Each instance gets smaller and attribute access slightly faster, which matters when you create millions of them. The cost: you can’t add attributes that aren’t listed, and you need a __weakref__ slot for weak references.

Keeping a single copy of equal strings. CPython interns identifiers and many short literals automatically, and you can intern others with sys.intern(), which saves memory and makes dict lookups on repeated keys faster. It’s an optimisation, not a rule, so always compare strings with ==, never is.

After fork, parent and child share memory pages until one of them writes to a page. In CPython, simply reading an object changes its reference count, which is a write, so shared pages are copied one by one. Immortal objects and gc.freeze() reduce this.

A list is a resizable array of pointers to objects stored elsewhere. When it’s full, CPython allocates a bigger array with spare room, so most appends just fill a free slot and the occasional copy averages out: amortised O(1). Inserting or deleting at the front is O(n), because every pointer after it moves.

Each element is a pointer (8 bytes) to a full int object (28 bytes or more) with its own header. array.array('q') or a NumPy array stores the raw 8-byte values next to each other instead, several times smaller and much faster to loop over in C.

A generator produces values one at a time and keeps only its paused frame between them. sum(x * x for x in range(10**8)) needs constant memory, while the list comprehension version builds a list of a hundred million ints first. The catch: a generator can only be consumed once.

A view on the memory of another object that supports the buffer protocol, such as bytes, bytearray or array. Slicing a memoryview doesn’t copy, so parsing a large binary buffer piece by piece stays fast and uses no extra memory.

A nested function keeps every variable it uses from the enclosing scope in a cell. As long as the function exists, for example stored as a callback, those objects can’t be freed, even if you only needed one small value from a huge one. Copy out what you need before defining the function.

A traceback references every frame it passed through, and every frame references its local variables. Storing an exception, for example in a list of errors, keeps all of those locals alive. That’s why Python deletes the name after except E as e:; store str(e) if you only need the message.

It keeps a reference to every argument and result it stores. With maxsize=None, or @cache, it grows forever. On a method it also stores self, which keeps every instance alive. Give it a bounded size, and cache functions rather than methods.

An integer that is unique to an object for as long as it’s alive. In CPython it’s the memory address. Once an object is freed, a new object can get the same address, so two different objects created one after the other can report the same id.

Without the GIL, counter updates from different threads would race. Free-threaded builds use biased reference counting: the thread that owns an object updates a local count without atomics, and other threads update a shared count atomically. Some objects use deferred counting, and memory comes from mimalloc instead of pymalloc.

The Global Interpreter Lock is a mutex in CPython that lets only one thread run Python bytecode at a time within an interpreter. It keeps the interpreter’s internals, such as reference counts, safe without fine-grained locking.

Because a thread releases the GIL while it waits: blocking I/O on sockets and files, and time.sleep, let other threads run. Many C extensions, such as NumPy and hashlib on large inputs, release it during heavy computation too.

Use processes (multiprocessing or concurrent.futures.ProcessPoolExecutor) so each worker has its own interpreter and GIL, move the hot loop into native code that releases the GIL, or run on the free-threaded build.

No. Threads can switch between any two bytecodes, so count += 1 (load, add, store) can interleave and lose updates, which is the race you can step through on this line. Protect shared state with threading.Lock, or pass data between threads with queue.Queue.

A thread waiting for the GIL asks for it after the switch interval, 5 ms by default (sys.getswitchinterval()), and the holder releases it at the next safe point. A thread that starts blocking I/O releases it straight away.

A separate CPython build without the GIL (PEP 703), added experimentally in 3.13 as python3.13t and officially supported from 3.14 (PEP 779). Threads can then run Python code on several cores at once, at some cost to single-threaded speed. sys._is_gil_enabled() tells you which mode you’re in.

asyncio for many concurrent I/O tasks with async libraries on a single thread. Threads for I/O with blocking libraries, or a handful of background tasks. Processes for CPU-bound pure Python, paying for start-up time and for pickling data between them.

A CPU-bound thread keeps the GIL for a whole switch interval at a time, so I/O threads that only need it for a moment after each read queue up behind it. Their latency grows even though the total work barely changes, as the Mixed workload on this line shows.

No, it’s part of CPython, the reference implementation. Jython and IronPython never had one, PyPy has its own, and since 3.13 CPython has an optional free-threaded build without it. The language only says what your program means, not how threads are scheduled.

It’s a simple way to keep the interpreter’s internals safe: reference counts, the allocator and built-in objects can be updated without a lock of their own. That keeps single-threaded code fast and makes C extensions easy to write, at the price of only one thread running Python bytecode at a time.

During blocking I/O (sockets, files, time.sleep), and inside C code that chooses to release it, such as many NumPy operations, hashlib on large inputs and zlib. While executing Python bytecode, the running thread also gives it up when another thread has waited for the switch interval, 5 ms by default.

Without it, every reference count change would need an atomic operation or a lock, which slowed single-threaded code in earlier attempts, and many C extensions quietly relied on the GIL for safety. PEP 703 solved this with biased reference counting, per-object locks and immortal objects, and ships as an opt-in build.

No. It compiles to several steps: load the value, add one, store it back, and a thread switch between the load and the store loses an update. Single operations on built-ins, such as list.append, happen to be atomic in CPython, but don’t rely on it; protect shared state with a Lock.

A Lock deadlocks if the thread holding it tries to acquire it again. An RLock (reentrant lock) lets the owning thread acquire it several times, and it’s released after the same number of releases. Use RLock when a locked method calls another locked method of the same object.

Always acquire locks in the same global order, hold them for as short a time as possible, use with so they’re always released, and never call unknown code, such as callbacks, while holding one. A timeout on acquire turns a silent hang into an error you can see.

Through queue.Queue. It does its own locking, blocks consumers until items arrive and producers when it’s full, and turns shared state into messages. For signalling, use threading.Event; to limit how many threads use a resource, Semaphore.

They share the concurrent.futures API, so the choice is about the work. Threads for I/O-bound tasks: cheap to start, share memory. Processes for CPU-bound tasks: they get around the GIL, but the function and its arguments must be picklable, and each call pays to send data to another process.

Starting processes, pickling every argument and result to move it between them, and a separate copy of the interpreter and data in each one. How processes start depends on the platform: spawn on Windows and macOS, forkserver on Linux since 3.14 (before that, fork).

The child gets a copy of memory, but only the thread that called fork. A lock held by any other thread at that moment stays locked forever in the child, so the child can hang on its first log call or allocation. Python 3.12 and later warn about it; prefer spawn or forkserver.

Send messages through a multiprocessing.Queue or Pipe; the data is pickled and copied. For large arrays, use multiprocessing.shared_memory, which gives every process the same bytes without copying. A Manager shares Python objects through a server process, which is convenient but slow.

No. It runs one thread, and tasks take turns at each await. That handles thousands of waiting connections cheaply, but a single blocking call such as time.sleep or requests.get freezes every task. Move blocking work off the loop with asyncio.to_thread or run_in_executor.

Concurrency is dealing with many things at once: tasks make progress by taking turns. Parallelism is doing many things at once: tasks run at the same moment on different cores. Threads under the GIL and asyncio give you concurrency; processes, and free-threaded Python, give you parallelism.

Often, yes. NumPy releases the GIL inside many operations on large arrays, so several threads can run them on different cores. The Python lines between those calls still take turns, so the win depends on how much of the time is spent inside NumPy.

Several isolated Python interpreters in one process. Since 3.12 each can have its own GIL (PEP 684), and 3.14 adds the concurrent.interpreters module and InterpreterPoolExecutor. You get parallelism with less overhead than processes, but objects aren’t shared; data is passed between interpreters.

Call sys._is_gil_enabled() (3.13 and later). A free-threaded build, usually named python3.13t or python3.14t, runs without it, but it turns the GIL back on when it imports a C extension that isn’t marked safe, unless you force it off with PYTHON_GIL=0 or -X gil=0.

No. Built-in objects lock themselves internally, so a list won’t be corrupted, but counter += 1 and check-then-act code race exactly as before, only more often, because threads now really run at the same time. You still need locks, and single-threaded code runs somewhat slower in that build.

threading.local() gives every thread its own copy of some attributes, such as a database connection. contextvars does the same for asyncio tasks, which share one thread, and also works with threads. For request-scoped data in async code, use contextvars.

You can’t kill one from outside. Give it a threading.Event and have it check the event regularly and return. A daemon thread (daemon=True) doesn’t stop the interpreter from exiting, but it’s killed without cleanup, so open files and transactions may be left half done.

Seven primitives (undefined, null, boolean, number, bigint, string and symbol) plus objects. Arrays, functions, dates, maps and class instances are all objects.

Eight strings: "undefined", "boolean", "number", "bigint", "string", "symbol", "object" and "function". typeof null is "object" because of a historical bug, so test for null with === null and for arrays with Array.isArray().

Default to ===, which never converts types. == applies conversion rules: null and undefined only equal each other, booleans become numbers, a string compared with a number becomes a number, and objects are turned into primitives. The one common use of == is x == null, which checks for null or undefined.

No. Everything is passed by value, but the value of an object variable is a reference. A function can mutate an object you pass in, but reassigning the parameter doesn’t change your variable. Python works the same way.

Spread, Object.assign and slice() copy one level, so nested objects stay shared. structuredClone copies deeply, including Map, Set, Date and circular references, but it throws on functions, and class instances come back as plain objects.

Numbers are 64-bit IEEE 754 doubles, and 0.1, 0.2 and 0.3 have no exact binary form, so each is stored as the nearest double and the rounding errors don’t cancel out. Compare with a tolerance, or keep money in integer cents.

false, 0, -0, 0n, "", null, undefined and NaN (plus the legacy document.all in browsers). Everything else is truthy, including "0", "false", [] and {}.

2⁵³ − 1. Above it, not every integer can be represented, so a 64-bit ID from a database can silently change when parsed as a number. Keep such IDs as strings or BigInt.

undefined means a value was never set: a missing property, an unassigned variable, a function with no return. null is an explicit “no value” that you assign. JSON has null but no undefined, and JSON.stringify drops properties whose value is undefined.

A bug from the first JavaScript engine: values carried a type tag, objects had tag 0, and null was the null pointer, which also read as 0. Changing it now would break the web, so it stays. Test for null with x === null.

Array.isArray(x). typeof says "object", and instanceof Array fails for arrays from another realm, such as an iframe or a vm context, because each realm has its own Array constructor.

The IEEE 754 value for an undefined result, like 0 / 0 or Number("abc"). Its type is number, and it isn’t equal to anything, itself included, so x === NaN is always false. Use Number.isNaN(x); the global isNaN converts first, so isNaN("abc") is true.

In exactly two cases: Object.is(NaN, NaN) is true, and Object.is(0, -0) is false. Everything else matches ===. React uses it to decide whether state changed, and Map, Set and includes use a variant that treats 0 and -0 as equal.

When you write "abc".toUpperCase(), the engine uses a temporary String wrapper to find the method on String.prototype; the primitive itself doesn’t change. Never create wrappers yourself with new String or new Boolean: new Boolean(false) is an object, so it’s truthy.

It calls obj[Symbol.toPrimitive](hint) if it exists. Otherwise it tries valueOf() then toString() for a number hint, and the other way round for a string hint. That’s why [] + {} is "[object Object]": [] becomes "", {} becomes "[object Object]", and + joins strings.

An integer type of any size, written 123n, with typeof "bigint". Use it for IDs, money in minor units or anything beyond 2⁵³. You can’t mix it with numbers in arithmetic (1n + 1 throws a TypeError), it has no fractions, and JSON.stringify throws on it.

A unique value, mostly used as a property key that can’t clash with any other key, even one with the same description. for...in, Object.keys and JSON.stringify skip symbol keys. Built-in ones like Symbol.iterator let your objects plug into language features such as for...of.

No. const only stops you from rebinding the name; the object it points at can still change. Object.freeze stops changes to the object’s own properties, but it’s shallow: nested objects stay mutable unless you freeze them too.

Prefer structuredClone: it copies Date, Map, Set, typed arrays and circular references. The JSON round trip drops undefined and functions, turns dates into strings and NaN into null, and throws on cycles and BigInt. Neither copies functions or keeps class prototypes.

A small integer that V8 stores inside the pointer itself, tagged by its lowest bit, so it needs no allocation. Numbers that don’t fit, such as fractions, -0 or large integers, become a HeapNumber: a 64-bit float in a separate heap object. That’s why integer-heavy code is often faster.

V8 gives every object a hidden class, or shape, that records its properties and where they are stored. Objects built with the same properties in the same order share a shape, so property access can be cached and becomes very fast. Adding properties in different orders, or using delete, creates new shapes and slows that code down.

V8 tracks what an array holds: only small integers, only doubles, or anything, and whether it has holes. Packed small-integer arrays are the fastest. Transitions only go one way: after arr.push(1.5) or a hole like arr[100] = 1, that array never becomes fast again. new Array(n) starts out holey.

IEEE 754 floats keep a sign bit even for zero. 0 === -0 is true, but 1 / -0 is -Infinity and Object.is(0, -0) is false. It shows up when a small negative value rounds to zero, and it can tell you which direction a value approached zero from.

Store integer minor units such as cents, with BigInt if they can get large, or use a decimal library, and format with Intl.NumberFormat. toFixed is not a fix: it rounds the binary value, so (1.005).toFixed(2) is "1.00", because 1.005 is really 1.00499999...

parseInt reads digits until it hits something else, so parseInt("12px") is 12. Number converts the whole string or returns NaN, so Number("12px") is NaN, but Number("") is 0. Always give parseInt a radix, and never pass it numbers: parseInt(0.0000005) is 5.

For x == null, which is true only for null and undefined, so it catches both in one check. Many style guides allow exactly that one case and use === everywhere else.

a || b falls back to b for every falsy value, including 0, "" and false. a ?? b falls back only for null and undefined. For defaults such as count ?? 10 you want ??, so that a real 0 is kept.

Use a Map for dictionaries with dynamic keys: keys can be any value, including objects, it has size, iterates in insertion order and has no inherited keys like __proto__ to worry about. Object keys are always strings or symbols, and integer-like keys are listed first, in numeric order. Use objects for records with fixed fields.

Attaching data to objects you don’t own without keeping them alive. Keys must be objects, and once a key is unreachable anywhere else, the entry can be garbage collected. Because entries can disappear at any time, a WeakMap can’t be iterated and has no size. Typical uses: caches and private data per DOM node.

list, dict, set and bytearray, plus most classes you write. int, float, complex, bool, str, bytes, tuple, frozenset, range and None are immutable: every “change” builds a new object.

It needs a __hash__ that never changes during its lifetime, and objects that compare equal must hash equally. Only hashable objects can be dict keys or set members, which is why a list can’t be a key but a tuple of hashable items can.

They compare equal and have the same hash, so the dict treats them as one key. The first key object is kept and only the value is replaced, as the hashing stepper on this line shows.

It calls a.__add__(b). If that returns NotImplemented, it tries b.__radd__(a), and raises TypeError if both give up. If b’s type is a subclass of a’s type that overrides __radd__, b goes first.

Not for mutable types. += calls __iadd__ first, which extends a list in place, so every name for that list sees the change. Immutable types fall back to x = x + y and rebind only x. That’s also why pair[0] += [2] on a tuple both mutates the list and raises.

Default values are evaluated once, when the function is defined, so every call shares the same list. Use items=None and create a new list inside the function.

None is a singleton, so identity is the precise test. It’s also faster, and it can’t be fooled by a class whose __eq__ says yes to everything.

A list for an ordered collection you change, a tuple for a fixed record or a hashable key, a set for uniqueness and fast membership tests, and a dict for lookup by key. Reach for a frozenset when you need a set that is hashable.

list(x), x.copy(), x[:] and copy.copy() are shallow: the new container holds the same inner objects. copy.deepcopy() copies everything recursively.

+= first calls list.__iadd__, which extends the list inside the tuple in place, then tries to store the result back into t[0], which raises TypeError. The tuple’s slots can’t change, but the objects in them can. For the same reason, a tuple that contains a list isn’t hashable.

Objects that compare equal must have equal hashes, and the hash must not change while the object is in a set or dict. That’s why defining __eq__ sets __hash__ to None: Python makes the class unhashable until you define a hash based on the same fields. @dataclass(frozen=True) does both for you.

It’s a hash table. The key’s hash picks a slot in a small index array, collisions are resolved by probing other slots, and the index points into a compact array of entries kept in insertion order. Lookups, inserts and deletes are O(1) on average, and a hit is confirmed with is or == on the key.

Yes, insertion order is guaranteed since Python 3.7. OrderedDict is still useful: it has move_to_end, its equality checks take order into account, and it’s handy for LRU caches. Sets have no order at all.

Python cares what an object can do, not what class it is: anything with __iter__ can be looped over, anything with read() can act as a file. Code usually just tries the operation and handles the exception (EAFP). For type checkers, typing.Protocol describes such a shape without inheritance.

NotImplemented is a value you return from a binary method such as __add__ or __eq__ to say “I don’t know this type”, so Python tries the other operand’s method. NotImplementedError is an exception you raise in a method that subclasses must override. Raising the first or returning the second are both bugs.

For a + b, when a has no __add__ or it returns NotImplemented, Python tries b.__radd__(a). One exception: if b’s type is a subclass of a’s type and overrides __radd__, it goes first, so subclasses can take control. It’s how sum() works on custom types starting from 0.

No. Python ignores them when it runs your code; tools such as mypy and pyright check them before it runs. They are available at runtime through typing.get_type_hints() and annotationlib, which is how libraries like Pydantic and FastAPI validate data. Since 3.14 annotations are evaluated lazily, only when something asks for them.

No, ints have arbitrary precision and grow as needed; sys.maxsize is the largest container size, not the largest int. Big ints just get slower. Since 3.11, converting an int with more than 4300 digits to or from a string raises ValueError by default, to prevent denial-of-service attacks.

// rounds down, towards minus infinity, so -7 // 2 is -4, and % takes the sign of the divisor: -7 % 2 is 1. JavaScript, C and Java truncate towards zero instead. int(-3.5) truncates too, giving -3.

Python rounds halves to the nearest even number (banker’s rounding), so round(2.5) is 2 and round(3.5) is 4; that avoids a bias when you add many rounded values. round(2.675, 2) gives 2.67 because 2.675 can’t be stored exactly. For money, use decimal.Decimal.

str is text, a sequence of Unicode code points. bytes is raw 8-bit data from files, sockets or hashes. Python 3 never converts between them implicitly: encode() text into bytes and decode() bytes into text at the edges of your program, naming the encoding, usually UTF-8.

len counts code points, not what you see. “é” can be one code point (U+00E9) or two: “e” plus a combining accent. Normalise with unicodedata.normalize("NFC", s) before comparing or counting. Internally, CPython stores each string with 1, 2 or 4 bytes per character, depending on its widest one.

Strings are immutable, so each += can create a new string and copy everything so far, which is O(n²) overall. CPython sometimes extends in place, but other implementations don’t, and you can’t rely on it. Collect the parts in a list and call "".join(parts) once, or use io.StringIO.

isinstance accepts subclasses and abstract base classes such as collections.abc.Mapping, which is almost always what you want. It has one classic surprise: bool is a subclass of int, so isinstance(True, int) is true and True + True is 2. Use type(x) is T only when subclasses must be rejected.

A list checks every element in turn: O(n). Sets and dicts hash x and look in one slot: O(1) on average. Turning a list into a set before checking thousands of values in a loop is one of the easiest big speed-ups. x in range(...) is O(1) too: it’s just arithmetic.

namedtuple: an immutable, lightweight tuple with field names. dataclass: a normal class with generated __init__, __repr__ and __eq__, mutable or frozen, with defaults and methods. TypedDict: type hints for dicts that stay plain dicts, such as JSON payloads. A plain dict: truly dynamic keys.

Yes. Python’s sort is stable, so items with equal keys keep their order, and you can sort by several keys in several passes, the least important first. It’s O(n log n) and very fast on data that is already partly sorted. It only needs <; mixing types that can’t be compared, like None and int, raises TypeError.

It calls __bool__ if the class defines it, otherwise __len__, and treats anything else as true. So None, False, zero of every numeric type and empty containers are falsy. Watch out for if not x: when 0 or an empty list is a valid value; write if x is None: instead.

An iterable, like a list, can give you a fresh iterator with iter(), as often as you like. An iterator remembers its position, returns the next item from __next__ and is used up after one pass. Generators and file objects are iterators, which is why looping over one a second time yields nothing.