Python Developer interview questions

functools.wraps preserves the decorated function's identity and exposes the original function for introspection.

• Without it, __name__ and __doc__ belong to the wrapper, so tracebacks, logs, documentation tools, and debugging show the wrong function.
• Libraries that dispatch on function metadata can misbehave, including pickling, functools.singledispatch, and framework route registration.
• wraps copies __name__, __doc__, __module__, and __dict__, then sets __wrapped__ so inspect.unwrap can reach the original function.

A decorator with arguments uses nested closures to carry its options through to call time.

• The outer factory receives arguments such as times=3 and returns the actual decorator.
• The decorator receives the function and returns a wrapper, which can access both the function and the options through closures.
• Parentheses are required even for defaults unless both forms are supported by checking whether the first positional argument is callable; the simpler alternative is to require and document parentheses.

Stacked decorators are applied from the function outward and entered in the opposite order at call time.

• Application is bottom-up: the decorator closest to def wraps the function first, and every decorator above wraps the previous result.
• Execution is top-down: the outermost wrapper runs first and delegates inward.
• The order affects behavior: a cache outside an auth check can cache responses for unauthorized users, while the reversed order makes every cache hit pass through auth.

__exit__ always gets a chance to clean up and can decide whether an exception leaves the with block.

• It receives the exception type, value, and traceback, or three None values when the block finishes normally.
• A truthy return suppresses the exception and continues execution after the with block, as contextlib.suppress does.
• Returning None or False propagates the exception, while cleanup in __exit__ still runs either way.

contextlib.contextmanager maps the two sides of a single yield to context entry and exit.

• Code before yield acts as __enter__, and the yielded value becomes the target after as.
• Code after yield acts as __exit__, so yield must be wrapped in try/finally to guarantee cleanup when the with body raises.
• The exception is thrown into the generator at yield, and catching it without re-raising suppresses it just like returning True from __exit__.

A generator suspends and resumes one preserved execution frame, enabling item-by-item processing.

• Calling a generator function runs none of its body and returns a generator object with a suspended frame.
• Each next() resumes execution until yield, returns the value, and suspends again while preserving locals and the instruction pointer.
• A pipeline such as parse(filter(read_lines(f))) can process each item through every stage and keep memory usage flat for a multi-gigabyte log.

Choose a list for reusable materialized data and a generator for lazy single-pass consumption.

• A list comprehension builds everything immediately, which suits length checks, multiple passes, indexing, and sorting.
• A generator expression yields lazily and works well with sum or any, where short-circuiting can avoid unnecessary work.
• A generator is wrong when the consumer iterates twice, because the second pass silently produces no items and raises no error.

yield from delegates the full generator protocol rather than only forwarding yielded values.

• For plain iteration it looks like a for loop with yield, but send() and throw() from the consumer are passed into the subgenerator.
• The subgenerator's return value becomes the value of the yield from expression, supporting generators that produce both a stream and a final result.
• This return-value plumbing powered pre-async coroutine frameworks, while a manual loop breaks the two-way communication.

Lambdas in a loop share one captured variable, so they observe its final value when called later.

• Closures capture variables rather than snapshots of their values, and the loop leaves its shared variable set to the last item.
• A default argument such as lambda x=x: ... binds the current value at definition time; functools.partial can store it explicitly instead.
• Without that binding, callbacks or handler dictionaries built in a loop make every handler act on the last item.

Default arguments are evaluated once at function definition, which is dangerous for mutable objects but useful for deliberate snapshots.

• def f(items=[]) reuses one list across calls, so appended values leak from one invocation to another.
• The standard fix is a None sentinel followed by items = [] if items is None else items inside the function.
• Definition-time binding can intentionally snapshot a loop value or cache an expensive lookup, although explicit caching mechanisms are preferable for the latter.

Descriptors centralize managed attribute behavior through methods on a class attribute's type.

• A descriptor defines __get__, __set__, or __delete__, and instance attribute access is routed through those methods via the class.
• property is a built-in descriptor that maps reads and writes to functions; functions are also descriptors whose __get__ creates bound methods.
• A custom descriptor is useful when logic such as field validation or unit conversion repeats across many attributes and would otherwise require many similar properties.

__slots__ trades dynamic instance attributes for fixed storage and lower per-instance memory use.

• It replaces each instance's __dict__ with storage for named attributes, significantly reducing memory and slightly speeding attribute access.
• Arbitrary runtime attributes are unavailable, weak references require an explicit __weakref__ slot, and a non-slotted parent restores __dict__ during inheritance.
• It is worthwhile for millions of instances such as AST nodes or tick data points, but ordinary domain classes often benefit more from flexibility.

dataclass generates common data-object methods from annotated fields and provides safe controls for immutability and defaults.

• It creates __init__, __repr__, and __eq__, with optional __hash__ and ordering methods, removing repetitive assignment-heavy constructors.
• frozen=True rejects attribute assignment, enabling hashability and safe use as dictionary keys.
• field(default_factory=list) calls a factory for every instance, avoiding the shared mutable default bug of a bare list.

== compares values through __eq__, while is checks whether two references point to the same object.

• Equal strings built at runtime can be distinct objects even though == returns True.
• CPython interns small integers and some compile-time strings, but behavior can change for concatenated or user-provided strings and across implementations.
• Use is for singletons such as None, True, False, and custom sentinel objects, never as a value comparison based on interning.

Shallow copying duplicates only the container, while deep copying recursively duplicates its object graph.

• copy.copy creates a new outer object whose elements remain the same references, so changing a nested list through the copy also changes the original.
• copy.deepcopy recursively copies the graph and uses a memo dictionary to handle cycles.
• A shallow config copy can leak a nested tenant change to everyone, but deep-copying huge structures in hot paths can cost more than redesigning the code to avoid mutation.

CPython needs cycle collection because reference counting alone cannot release unreachable objects that reference each other.

• Reference counting frees an object when its count reaches zero, but members of a cycle keep one another above zero.
• The generational cyclic collector periodically finds these unreachable groups; __del__ complicates this because finalization order in a dying cycle is ambiguous.
• Such cycles historically remained uncollected and are handled today with potentially surprising finalizer order, so resource cleanup is better done with context managers or weakref.finalize.

The GIL protects CPython interpreter internals, not the thread safety of application-level operations.

• It allows only one thread to execute Python bytecode at a time, preventing corruption of interpreter state such as reference counts.
• Multi-bytecode actions such as check-then-update or += on a shared attribute can still interleave, causing races and lost updates.
• The GIL is released around blocking I/O and inside many C extensions, which is why threads can still improve I/O-bound workloads.

Threads overlap blocking waits in I/O-bound work but serialize CPU-bound Python execution under the GIL.

• A thread releases the GIL during a blocking socket read or database call, allowing other threads to run and increasing throughput across concurrent waits.
• CPU-bound threads do not wait and instead contend for one GIL, so work is serialized and can be slower because of switching overhead.
• CPU-heavy work can use multiprocessing, C extensions such as numpy that release the GIL internally, or another runtime.

Type hints and mypy should be introduced incrementally while protecting every module that has already become typed.

• Start with permissive mypy settings, add stricter per-module overrides, and gate CI so clean modules cannot regress.
• Type all new code and prioritize the shared core, models, and utilities, where annotations catch the most downstream mistakes.
• Avoid a single annotation change across thousands of files because the diff becomes stale in review while feature work continues.

Type safety usually leaks through Any and through unchecked escape hatches such as casts and ignores.

• Untyped libraries, json.loads results, and unannotated functions produce Any, which propagates silently and disables downstream checking.
• Tighten mypy with disallow_untyped_defs and warn_return_any, then parse external data at the boundary into TypedDict, dataclass, or pydantic models instead of passing raw dictionaries.
• Require a reason for casts and type: ignore directives, and search for them periodically so they can be removed.