CPython (the standard Python) uses reference counting for memory management. Every object has a counter — how many variables point to it. When that counter hits zero, the object is freed. The problem? Reference count updates are NOT thread-safe by default. Two threads incrementing/decrementing the same counter simultaneously = corruption.

The GIL is the brutal but simple fix: "Only one thread runs Python bytecode at a time, period." It's like a single baton in a relay race — a thread must hold the GIL to run, and it releases it periodically (every 5ms in Python 3.2+) or during I/O so other threads get a turn.

This means Python threads are concurrent (they take turns) but NOT parallel (they don't run simultaneously on multiple cores). For CPU-heavy tasks, threads give you zero speedup — you're still using one core. For I/O-heavy tasks (network calls, file reads), threads work fine because the GIL is released during I/O waits.

This is the direct consequence of the GIL. For I/O-bound tasks (web scraping, API calls, reading files), use threading — the GIL gets released during I/O, threads can overlap their wait times, and you get real speedup with low overhead.

For CPU-bound tasks (image processing, number crunching, data transformation), use multiprocessing — each process is a separate Python interpreter with its own GIL, so they run truly in parallel on multiple cores. The cost: each process has its own memory copy, and communication between processes requires pickling (serializing) data.

There's also asyncio — a third option. It's single-threaded, single-process, but uses event loops and coroutines. Perfect when you have thousands of I/O operations and the overhead of threads is too high. Think web servers handling 10k concurrent connections.

In Python, everything is an object. When you do x = 5, x is a variable that points to the integer object 5. When you do x = x + 1, you're not changing the 5 — you're making x point to a new integer object 6. The original 5 is untouched. That's immutability.

With a list, my_list.append(4) actually modifies the same list object in memory. Any other variable pointing to that same list will see the change. This is why passing a list to a function and modifying it inside changes the original — they both point to the same object.

Python uses integer caching (small ints -5 to 256 are pre-created and shared). So a = 5; b = 5; a is b is True — both point to the same cached int object. This can confuse people with the is operator.

Think of == as "do these two objects look the same?" and is as "are these the exact same person, not just a twin?" Two different list objects with identical contents will pass == but fail is, because they're two separate objects in memory.

Python caches small integers (-5 to 256) and interned strings, so a = 5; b = 5; a is b will be True. But a = 1000; b = 1000; a is b might be False — Python doesn't cache large integers. This behavior is an implementation detail, not a language guarantee.

Imagine you have a list of lists. Shallow copy gives you a new outer list, but the inner lists are the same objects as the original. Modify an inner list — both copies see the change.

Deep copy creates completely new objects at every level. Change anything in the deep copy — original is untouched. Use copy.copy() for shallow, copy.deepcopy() for deep.

Every Python object has a reference count — a number tracking how many variables/containers point to it. When you do x = obj, obj's refcount goes up. When x goes out of scope or you do del x, refcount goes down. When refcount hits 0 — the object is immediately freed. No GC pause needed.

But reference counting alone can't handle circular references. If object A has a reference to B, and B references back to A, even when all external references are gone, both have refcount 1. They'll never be freed. Python's cyclic GC runs periodically to detect and clean these up.

Memory is not directly requested from the OS for each object. Python maintains a private heap and uses an allocator called pymalloc that manages small objects (≤512 bytes) efficiently using fixed-size memory pools — much faster than calling malloc for every tiny object.

When you run python script.py, Python first reads your source code and tokenizes it — breaks it into meaningful chunks (keywords, identifiers, operators). Then a parser turns those tokens into an Abstract Syntax Tree (AST) — a tree structure representing the logical structure of your code.

A compiler then converts the AST into bytecode — a sequence of low-level instructions for the CPython VM. This bytecode is cached in __pycache__/*.pyc files so next time you run the same script, the tokenize/parse/compile steps are skipped.

Finally, the CPython Virtual Machine — basically a giant loop — reads bytecode instructions one by one and executes them. Unlike Java's JVM, CPython is a pure interpreter. There's no JIT compilation by default (though PyPy has JIT).

The practical rule: use a list when you have a collection that might grow or change (a list of user inputs, results to accumulate). Use a tuple when the data is fixed (coordinates, RGB color, a function returning multiple values, dict keys).

Because tuples are immutable, CPython can make some optimizations — tuple literals are often pre-created at compile time rather than at runtime. Tuple creation is faster, and tuples take slightly less memory than equivalent lists.

Normal function: call it → runs to completion → returns a value. Generator function: call it → returns a generator object (nothing executes yet). Every time you call next() on it, execution runs until the next yield, pauses there, and hands back the yielded value. The function's local state is preserved between calls.

The magic: only one value exists in memory at a time. If you need to process a 10GB log file line by line, a generator gives you one line at a time. A list would try to load all 10GB into RAM and crash.

Generator expressions are like list comprehensions but with () instead of []: (x*2 for x in range(1000000)) uses constant memory. [x*2 for x in range(1000000)] creates a million-element list immediately.

This question trips many people because the answer is nuanced. Traditionally, compilers translate source code to machine code all at once before running (C, C++, Rust). Interpreters execute source code line-by-line without producing a separate binary (old BASIC interpreters).

Python is a hybrid. It has a compilation phase (source → bytecode) that happens when you run the script. Then it has an interpretation phase (bytecode → execution) by the CPython VM. The bytecode is not machine code — it's still an intermediate language that the VM interprets at runtime.

CPython = interpreted. PyPy = JIT compiled — takes Python bytecode and compiles hot code paths to native machine code on the fly. This is why PyPy can be dramatically faster for CPU-bound code. Cython = transpiles Python-like code to C, then compiles to machine code. Nuitka = compiles Python to C/machine code.