Python · Advanced interview

The Global Interpreter Lock is a mutex in CPython that lets only one thread execute Python bytecode at a time, protecting the interpreter's memory management. The implication: threads don't give you parallel speedup for CPU-bound Python code, but they're fine for I/O-bound work because the GIL is released during blocking I/O. CPU parallelism needs multiprocessing or C extensions that release the GIL. (Recent CPython has experimental free-threaded builds that remove it.)

asyncio for high-concurrency I/O with cooperative tasks in one thread (thousands of sockets) when your libraries are async. threading for I/O-bound work with blocking libraries, where the GIL releases during I/O. multiprocessing (or a process pool) for CPU-bound work, to get true parallelism across cores at the cost of memory and inter-process communication. The deciding question is I/O-bound vs CPU-bound, then library support.

A coroutine (async def) is a function you can pause at await points. The event loop runs a single thread, switching between coroutines whenever one awaits something not yet ready, so many I/O operations overlap without threads. The catch is cooperative scheduling: a coroutine that does blocking work or heavy CPU without awaiting starves the loop, so blocking calls must be offloaded to an executor.

Primarily by reference counting — each object tracks how many references point to it and is freed immediately when that hits zero. Because reference counting alone can't reclaim reference cycles, a generational cyclic garbage collector periodically finds and frees unreachable cycles. CPython also pools small objects and integers. Knowing this explains why deleting a name doesn't always free memory and why cycles need the GC.

Functions, classes, modules, and even types are first-class objects with attributes you can pass around, reassign, and introspect. Variables are names bound to objects, not boxes holding values, so assignment binds a name and 'mutating through one name' is visible through another bound to the same object. This model underlies decorators, higher-order functions, monkey-patching, and the aliasing gotchas with mutable defaults.

By default each instance stores attributes in a per-instance __dict__, which is flexible but memory-heavy. Declaring __slots__ with a fixed set of attribute names tells Python to store them in a compact structure instead, saving significant memory and slightly speeding attribute access — valuable when you create millions of small objects. The trade-off is you can't add arbitrary attributes and it complicates multiple inheritance.

A metaclass is the 'class of a class' — it controls how classes are created, the way a class controls how instances are created (type is the default). You'd use one to enforce constraints on subclasses, auto-register classes, or inject methods at class-creation time, as ORMs and frameworks do. In practice most needs are now met by __init_subclass__ or class decorators, so genuine metaclasses are rare.

A descriptor is an object implementing __get__/__set__/__delete__ that, when assigned to a class attribute, customizes what attribute access does. property is a built-in descriptor that routes attribute reads/writes through getter/setter functions. Descriptors are the machinery behind property, classmethod, staticmethod, and ORM fields — they're how 'an attribute' can run code.

Python computes a linear order of classes (the MRO) using the C3 linearization, which respects the order of base classes and ensures each ancestor appears after its subclasses. super() follows this MRO rather than just the literal parent, so in a diamond hierarchy a cooperative super() call visits each class once. You can inspect it via Class.__mro__; understanding it is key to making multiple inheritance behave.

Measure first: cProfile for function-level hotspots, line_profiler for line-level, and a memory profiler if memory is the issue — never guess. Then attack the actual hotspot: better algorithms/data structures, caching (lru_cache), moving tight loops to vectorized NumPy or a C extension, reducing per-call overhead, and only then concurrency. Re-measure after each change.

CPython is an interpreter with dynamic typing and per-operation object overhead, so tight numeric loops pay a heavy cost per element. Libraries like NumPy, pandas, and ML frameworks push the loop down into precompiled C/Fortran that operate on contiguous arrays and release the GIL, so you express the work as vectorized operations instead of Python loops. Tools like Cython, Numba, and writing C extensions do the same for custom hotspots.

Add type hints and run a static checker (mypy/pyright) in CI to catch type errors the dynamic runtime won't. Type the public boundaries first, use precise types (Protocol for structural interfaces, generics, Literal/TypedDict) where they add safety, and gate new code as strict while incrementally typing legacy. Hints also improve editor support and serve as living documentation, at the cost of some upfront annotation effort.