Question 1

What is Python's GIL, what does it protect, and what are its limitations?

Accepted Answer

The Global Interpreter Lock (GIL) is a mutex inside CPython that ensures only one thread executes Python bytecode at any given moment. It is not a feature of the Python language itself but an implementation detail of CPython, the reference implementation.

The GIL exists primarily to protect CPython's memory management system. CPython tracks object lifetimes using reference counting -- every object has a refcount field that is incremented when a new reference is created and decremented when one is released. When refcount reaches zero, the object is deallocated. Without the GIL, two threads could simultaneously increment or decrement the same refcount, corrupting it and causing either memory leaks or premature deallocation (use-after-free). Making every refcount operation thread-safe with fine-grained locking would be technically possible but would add significant overhead to every object creation and deletion. The GIL is a coarser, simpler solution.

The practical implications are significant. For CPU-bound workloads -- numerical computation, string processing, pure Python loops -- using threads does not give you parallelism. Multiple threads compete for the GIL, so only one runs at a time. The correct tool for CPU-bound parallelism in Python is the multiprocessing module, which spawns separate processes that each have their own GIL and Python interpreter, achieving true parallelism across CPU cores.

For I/O-bound workloads, threads remain useful. The GIL is released while a thread waits for I/O -- for example, during a network request or disk read. While one thread waits, others can run. This is why frameworks like Django historically used threading for concurrent request handling.

In Python 3.13, CPython added experimental support for running without the GIL (PEP 703, free-threaded mode). This required atomic refcounting and fine-grained locking throughout the interpreter. It is not yet the default and comes with performance trade-offs in single-threaded code.

Question 2

What is the difference between ThreadPoolExecutor and ProcessPoolExecutor?

Accepted Answer

Both ThreadPoolExecutor and ProcessPoolExecutor are part of Python's concurrent.futures module and provide a high-level interface for running callables asynchronously using a pool of workers. The key difference is the unit of concurrency and how Python's GIL affects them.

ThreadPoolExecutor creates a pool of OS threads within the same process. All threads share the same memory space, the same Python interpreter state, and the same GIL. Because of the GIL, only one thread executes Python bytecode at a time. This means ThreadPoolExecutor does not achieve CPU parallelism for CPU-bound tasks -- threads take turns. However, the GIL is released during I/O operations (network, disk, subprocess calls) and during many C extension calls. For I/O-bound workloads -- making hundreds of concurrent HTTP requests, reading files, querying databases -- ThreadPoolExecutor is effective and has low overhead. Shared memory means threads can directly access shared Python objects, but this requires careful synchronization.

ProcessPoolExecutor creates a pool of separate OS processes. Each process has its own Python interpreter, its own GIL, and its own memory space. This means multiple CPU cores can run Python bytecode in parallel simultaneously. CPU-bound tasks -- numerical processing, data transformation, cryptographic operations -- run genuinely concurrently. The trade-offs are significant: process startup is expensive (tens to hundreds of milliseconds each), and all data communicated between the main process and workers must be serialized via pickle. Functions passed to the pool must be picklable (no lambdas, no closures over non-picklable objects). The memory overhead is high because each process is a full Python runtime.

The practical decision rule: use ThreadPoolExecutor for I/O-bound work where tasks spend most of their time waiting. Use ProcessPoolExecutor for CPU-bound work where tasks actively compute. Use neither and reach for asyncio if your I/O-bound work is highly concurrent and you want lower overhead than threads. A common production pattern is asyncio for the event loop with a ThreadPoolExecutor via loop.run_in_executor for blocking I/O calls that lack async APIs.

Question 3

How do decorators work under the hood in Python?

Accepted Answer

A decorator in Python is a callable -- typically a function -- that takes a function as an argument and returns a new callable. The @decorator syntax is pure syntactic sugar. Writing @log_calls above a function definition is exactly equivalent to writing f = log_calls(f) after the def statement. The decorator is applied at class or module load time, not at call time.

The most common pattern is a wrapper function. The decorator defines an inner function (the wrapper) that calls the original function, adding behavior before or after -- logging, timing, authentication, retry logic. The decorator returns the wrapper. From the caller's perspective, they are calling the original function, but they are actually calling the wrapper.

A critical implementation detail: without functools.wraps, the wrapper function replaces the original function's __name__, __doc__, and other attributes. This breaks introspection tools, documentation generators, and test frameworks that rely on function names. functools.wraps(original) applied to the wrapper copies these attributes from the original to the wrapper. Always use it in production decorators.

Decorators can also be parameterized -- meaning the decorator itself takes arguments. In this case, you need an extra level of nesting: a factory function that takes the parameters and returns the actual decorator. For example, @retry(max_attempts=3) is a call to retry(max_attempts=3) which returns a decorator, which is then applied to the function. This is three levels: factory, decorator, wrapper.

Class-based decorators are also valid. A class that implements __call__ can be used as a decorator. This is useful when the decorator needs to maintain state across calls such as a call counter.

Decorators stack. When you apply multiple decorators, they are applied bottom-up: the one closest to the def runs first, wrapping the function, then the outer decorator wraps the result. Order matters -- a caching decorator inside an authentication decorator caches authenticated results; reversed, it caches before checking auth.

Common real-world uses: @staticmethod and @classmethod (built-in), @property, @functools.lru_cache, Flask's @app.route, and authentication or rate-limiting middleware in web frameworks.

Question 4

How do generators and the yield keyword work in Python?

Accepted Answer

A generator in Python is a special type of iterator. Unlike a regular function that computes its entire result and returns it, a generator produces values one at a time and suspends execution between each value. This lazy evaluation model enables processing of large or infinite sequences without materializing them in memory.

A generator function is defined like a regular function but contains one or more yield statements. When you call a generator function, it does not execute the function body -- it returns a generator object immediately. The body only starts running when you call next() on the generator. Execution proceeds until the next yield statement, at which point the yielded value is returned to the caller and the function's execution state -- local variables, instruction pointer, everything -- is suspended. The next call to next() resumes exactly where it left off. When the function body exhausts, a StopIteration exception is raised, signaling the iterator is exhausted.

Memory efficiency is the primary benefit. A generator that yields one million numbers uses O(1) memory -- it holds only the current execution frame. A list of one million numbers uses O(n) memory. For pipelines processing large datasets -- reading lines from a file, transforming records -- chaining generators keeps the entire pipeline at O(1) memory overhead.

Generator expressions provide a compact syntax analogous to list comprehensions: (x * 2 for x in range(10)) returns a generator rather than a list.

yield from is a delegation mechanism introduced in Python 3.3. It allows a generator to delegate to another iterable or generator, flattening the delegation without manually iterating in a loop. It also properly forwards send() values and exceptions, which matters for coroutine-style code.

Generators also support the send() method, which allows the caller to send a value back into the generator, making generators a building block for coroutines. Python's asyncio async/await syntax is built on generators at the lower level. Understanding generators is prerequisite to understanding how the event loop and coroutines work internally.

Question 5

What are context managers and how do you implement one?

Accepted Answer

A context manager is an object that defines a setup and teardown protocol for a block of code, ensuring cleanup happens reliably regardless of whether the block exits normally or via an exception. The with statement invokes this protocol.

The protocol has two methods. __enter__(self) is called when execution enters the with block; its return value is bound to the name after as (if provided). __exit__(self, exc_type, exc_val, exc_tb) is called when the block exits -- whether normally, via a return, or via an exception. If __exit__ returns a truthy value, any exception is suppressed; if it returns False or None, the exception propagates.

A class-based context manager implements both methods directly. The canonical example is a file: open() returns an object whose __enter__ returns the file handle and whose __exit__ closes the file. Database connection context managers commit the transaction in __exit__ on success and roll it back on exception. Lock context managers acquire the lock in __enter__ and release it in __exit__.

For simpler use cases, the contextlib.contextmanager decorator allows writing a context manager as a generator function. The code before yield is __enter__; the value yielded is the as target; the code after yield runs as __exit__. A try/except around the yield handles exceptions from inside the with block. This approach is more concise for one-off context managers.

Context managers are the correct pattern for any resource that needs paired setup and teardown: files, database connections, network sockets, locks, transactions, temporary directories, mocked objects in tests (unittest.mock.patch is a context manager), and timing or profiling blocks. They replace try/finally blocks and eliminate the class of bugs where cleanup code is accidentally skipped.

Contextlib provides several ready-made utilities: contextlib.suppress to suppress specific exceptions, contextlib.nullcontext as a no-op for conditional context use, and contextlib.asynccontextmanager for async context managers.

Question 6

What is the LEGB rule in Python's scope resolution?

Accepted Answer

LEGB is Python's name resolution order: when the interpreter encounters a variable name, it searches scopes in this sequence: Local → Enclosing → Global → Built-in. The first scope where the name is found wins.

Local scope is the innermost function body currently executing. Variables assigned inside a function are local to that function by default — Python determines this at compile time, not runtime, so if a name is assigned anywhere in a function, it's treated as local throughout that function's scope (which causes the UnboundLocalError trap described below).

Enclosing scope covers any enclosing function scopes between the local function and the module level — the mechanism that makes closures work. A nested function can read variables from its enclosing function's scope. In Python 3, the `nonlocal` keyword allows a nested function to rebind (not just read) a variable in the enclosing scope.

Global scope is the module's top-level namespace. Variables defined at module level, or explicitly declared with the `global` keyword inside a function, live here. The `global` keyword tells Python to look up and bind the name in the module's global namespace instead of creating a local.

Built-in scope is the `builtins` module — containing `len`, `print`, `range`, `Exception`, etc. It's always available as the final fallback.

A common trap: the UnboundLocalError. If you read a variable before assigning it in the same function, Python has already classified it as local (because there's an assignment later in the function body) but hasn't assigned it yet at the point you read it. The fix is `global` or `nonlocal` depending on where the variable lives, or restructure to avoid the pattern.

Closures and LEGB interact importantly: a closure captures the enclosing scope's variable reference, not its value at the time of creation. The classic loop-closure bug (`lambda: i` in a for loop capturing the same `i`) stems from this. Default argument binding (`lambda i=i: i`) or `functools.partial` are the fixes.

Python's scoping is lexical (static) — determined by where code is written, not by the call stack at runtime.

Question 7

Explain Python's MRO, how super() works, and the diamond problem.

Accepted Answer

Python's Method Resolution Order (MRO) determines which class's method is called when a name is looked up in an inheritance hierarchy. For single inheritance, this is trivial. For multiple inheritance, Python uses C3 linearization, an algorithm that produces a consistent, predictable linear ordering of all classes in the hierarchy.

The diamond problem is the motivating case: class D inherits from B and C, both of which inherit from A. If D calls a method defined in A, which path wins — D→B→A or D→C→A? Worse, if B and C both override the method, which override runs? Without a defined resolution order, the answer is ambiguous and depends on implementation.

C3 linearization produces an MRO that satisfies three properties: the class itself comes first; a class always appears before its parents; if multiple bases are specified, their relative order from the class definition is preserved. For the diamond D(B, C), D's MRO is [D, B, C, A, object]. You can inspect this at runtime with `ClassName.__mro__` or `ClassName.mro()`.

`super()` is the mechanism for traversing the MRO cooperatively. Crucially, `super()` does not mean 'call the parent class' — it means 'call the next class in the MRO of the original instance's class.' This distinction matters: when B calls `super().__init__()` inside `D.__init__()`, super() resolves to C (the next in D's MRO), not to A. If each class in the chain calls `super()`, all `__init__` methods run exactly once, in MRO order, without A being initialized twice.

This is cooperative multiple inheritance. It only works correctly when all classes in the hierarchy use `super()` consistently. Mixing `super()` calls with explicit parent calls (like `A.__init__(self)`) breaks the cooperation and can cause A to be called twice or skipped.

A practical implication: `super()` in Python 3 is zero-argument and uses `__class__` cell references — you no longer need to pass the class name explicitly as in Python 2. `super()` == `super(__class__, self)`.

When multiple inheritance is genuinely needed, mixins are the typical pattern: small, focused classes that add one capability and always use `super()`, designed to be composed into a target class without direct instantiation.

Question 8

How does @property work as a getter, setter, and deleter?

Accepted Answer

Python's `@property` decorator turns a method into a descriptor that's accessed like an attribute — `obj.name` instead of `obj.name()`. This lets you expose a clean attribute interface while executing code (validation, computation, lazy loading) on access or assignment.

The getter is defined with `@property`. It runs when the attribute is read: `obj.temperature`. If you only define a getter, the attribute is read-only — attempting to assign raises `AttributeError: can't set attribute`.

The setter is defined with `@temperature.setter` (using the property's name). It runs when the attribute is assigned: `obj.temperature = 37`. The setter receives the new value as an argument. This is where you typically validate: raise `ValueError` for out-of-range values, coerce types, or trigger side effects like invalidating a cache.

The deleter is defined with `@temperature.deleter`. It runs when `del obj.temperature` is executed. Less commonly needed, but useful for releasing resources, clearing cached values, or resetting to a default state.

The full pattern in practice:
```python
class Circle:
    def __init__(self, radius):
        self._radius = radius  # underscore: internal storage

@property
    def radius(self):
        return self._radius

@radius.setter
    def radius(self, value):
        if value < 0:
            raise ValueError("Radius must be non-negative")
        self._radius = value

@radius.deleter
    def radius(self):
        del self._radius
```

A critical point: the property and its setter/deleter must share the same name. The decorator syntax `@radius.setter` works because `@property` returns a property object with `.setter()`, `.getter()`, and `.deleter()` methods that return new property objects with the respective accessor replaced.

The key design benefit: you can start with a plain attribute, then refactor to a property with validation later — all callers continue to use `obj.radius` unchanged. This is why Pythonistas don't write getters and setters upfront like in Java — you pay the property cost only when you need it.

Properties are implemented as descriptors, which is the broader protocol Python uses for attribute access control (`__get__`, `__set__`, `__delete__`). `property` is a built-in descriptor class.

Question 9

What are __slots__ and why would you use them?

Accepted Answer

By default, every Python instance stores its attributes in a per-instance dictionary (`__dict__`). This dictionary is flexible — you can add arbitrary attributes at runtime — but it carries significant overhead: a dict object requires ~200-300 bytes of baseline memory, plus the hash table's load factor means it's often sparse.

`__slots__` replaces `__dict__` with a compact, fixed-size array of slot descriptors defined at class creation time. You declare it as a class variable:

```python
class Point:
    __slots__ = ('x', 'y')
    def __init__(self, x, y):
        self.x = x
        self.y = y
```

When Python sees `__slots__`, it creates a descriptor for each slot name on the class and skips allocating `__dict__` for instances. Attribute access resolves through the descriptor protocol directly to a memory offset, rather than a dict lookup.

The two concrete benefits are memory and speed. Memory reduction is typically 40-60% per instance. For a class with two float attributes, a slotted instance uses ~56 bytes vs ~360 bytes with `__dict__`. Speed improvement on attribute get/set is ~15-30% due to eliminating hash computation.

Critical caveats:

**Inheritance:** If any class in the MRO omits `__slots__`, the `__dict__` is re-introduced by that parent. For the optimization to hold, every class in the inheritance chain must declare `__slots__`. This includes explicitly setting `__slots__ = ()` on intermediary base classes.

**Pickling and `__weakref__`:** Slotted classes cannot be weakly referenced unless `'__weakref__'` is included in `__slots__`. Pickling requires either `__getstate__`/`__setstate__` or including `'__dict__'` in slots (which defeats most of the memory benefit).

**No dynamic attributes:** You cannot add undeclared attributes to slotted instances at runtime. This is a behavioral change, not just an optimization.

**dataclasses and attrs:** Both support slots via `@dataclass(slots=True)` (Python 3.10+) and `@attr.s(slots=True)`, which handle the implementation details including inheritance and pickle support.

Use `__slots__` when you're creating millions of instances (e.g., nodes in a graph, event objects, parsed records from a large dataset) and memory profiling confirms `__dict__` overhead is significant. Do not use it speculatively — it adds complexity and removes flexibility.

Question 10

What is the difference between @classmethod, @staticmethod, and @property?

Accepted Answer

These three decorators are distinct tools that change how a method receives arguments and how it is invoked — understanding them requires understanding Python's descriptor protocol.

**@staticmethod** is the simplest. It converts a function so that it receives no implicit first argument. The method is logically grouped inside the class for organizational purposes but has no access to the instance or the class. Use it for pure utility functions that conceptually belong with the class but don't need class or instance state.

```python
class MathUtils:
    @staticmethod
    def clamp(value, low, high):
        return max(low, min(value, high))
```

**@classmethod** passes the class itself (`cls`) as the first argument instead of the instance. It is inherited polymorphically — `cls` refers to the actual subclass when called on a subclass, not the class where the method is defined. The primary use case is alternative constructors (factory methods):

```python
class Date:
    @classmethod
    def from_string(cls, s):
        year, month, day = map(int, s.split('-'))
        return cls(year, month, day)  # respects subclassing
```

Other uses: accessing or modifying class-level state, and registry patterns.

**@property** makes a method callable like an attribute. It implements the descriptor protocol with `__get__`, `__set__`, and `__delete__` hooks via `.setter` and `.deleter` sub-decorators. Properties enforce encapsulation: expose a clean attribute interface while hiding implementation, validate on assignment, or compute derived values lazily:

```python
class Circle:
    def __init__(self, radius):
        self._radius = radius

@property
    def radius(self):
        return self._radius

@radius.setter
    def radius(self, value):
        if value < 0:
            raise ValueError('Radius must be non-negative')
        self._radius = value

@property
    def area(self):
        return 3.14159 * self._radius ** 2
```

Key distinction: `@classmethod` and `@staticmethod` are about argument passing; `@property` is about attribute access semantics. You can combine `@classmethod` with `@property` in Python 3.9+ (deprecated in 3.13 in favor of explicit descriptors), but this is rarely necessary.

In interviews, ground your answer in a concrete use case for each rather than an abstract description.

Question 11

What is the difference between 'is' and '==' in Python?

Accepted Answer

In Python, `is` and `==` are fundamentally different operations that are often confused because they coincidentally produce the same result in common cases.

`==` calls `__eq__()` on the left-hand operand. It tests **value equality** — whether two objects represent the same value according to the class's definition. For built-in types, this is intuitive: `[1, 2] == [1, 2]` is `True` even though they are distinct list objects.

`is` tests **object identity** — whether two names refer to the exact same object in memory. It is equivalent to `id(a) == id(b)`. It does NOT call `__eq__`. No overriding is possible.

The dangerous trap is CPython's optimization of caching small integers (typically -5 to 256) and interned string literals. Because these objects are cached and reused, `is` appears to work:

```python
a = 256
b = 256
a is b  # True — same cached object

a = 257
b = 257
a is b  # False in most contexts — different objects
```

Similarly with strings:

```python
'hello' is 'hello'  # True — interned
'hello world' is 'hello world'  # May be False
```

This behavior is a CPython implementation detail, not guaranteed by the language specification. Code relying on it is not portable across Python implementations (PyPy, Jython) and can break with dynamic string construction.

**Correct usage of `is`:** Comparing to singletons — `None`, `True`, `False`. PEP 8 explicitly recommends `if x is None` over `if x == None`. This is both more semantically accurate (you mean identity) and safe because `==` can be overridden (`__eq__` might do something unexpected on a custom class).

**When `==` is what you want:** Virtually always, when comparing values — numbers, strings, lists, custom objects. Define `__eq__` on your classes to control equality semantics.

A common bug pattern: checking `if result is True` when a function returns a truthy non-True value (e.g., 1 or a non-empty list). Use `if result == True` or better `if result`.

Question 12

Why are mutable default arguments dangerous in Python?

Accepted Answer

In Python, default argument values are evaluated **once** when the `def` statement is executed — not each time the function is called. For immutable defaults like integers, strings, or `None`, this is harmless because they cannot be modified in place. For mutable defaults like lists, dicts, or sets, this becomes a subtle and persistent bug.

The canonical example:

```python
def append_to(element, to=[]):
    to.append(element)
    return to

append_to(1)  # [1]
append_to(2)  # [1, 2] — not [2]!
append_to(3)  # [1, 2, 3]
```

All three calls share the same list object. The default `[]` is stored in `append_to.__defaults__[0]` and lives for the lifetime of the function object. Each mutation persists across calls because no new list is created.

Why does Python work this way? Default values are computed at definition time for performance and to allow complex objects (like compiled regexes) to be cached as defaults. It is a deliberate design decision, not an oversight — but it consistently surprises developers.

The idiomatic fix is the **sentinel pattern**: use `None` as the default and create the mutable object inside the function body:

```python
def append_to(element, to=None):
    if to is None:
        to = []
    to.append(element)
    return to
```

Now each call that omits `to` gets a fresh list. Callers who explicitly pass a list get mutation on that list, which is expected.

The same bug applies to dicts and custom objects:

```python
def add_user(name, cache={}):
    cache[name] = True
    return cache
```

Python dataclasses handle this correctly by requiring `field(default_factory=list)` for mutable defaults and raising a `ValueError` if you try to assign a mutable default directly. This is an intentional guardrail.

The pattern is also intentionally exploited in rare cases: a mutable default as a function-level cache (poor man's `functools.lru_cache`). But this is an advanced idiom, not a recommendation for general use.

In code review, any mutable default argument should be flagged. Linters like `flake8` (B006 via `flake8-bugbear`) catch this automatically.

Question 13

What is the difference between deepcopy and shallow copy?

Accepted Answer

Copying in Python has three distinct levels: assignment, shallow copy, and deep copy. Choosing the wrong one causes aliasing bugs that are difficult to debug.

**Assignment (`b = a`)** creates no copy at all. Both names refer to the same object. Any mutation through either name is visible through the other.

**Shallow copy** creates a new top-level container object but populates it with references to the same child objects. For a list, `b = a.copy()` or `b = a[:]` creates a new list, but the elements inside are not copied — they are shared.

```python
import copy

a = [[1, 2], [3, 4]]
b = copy.copy(a)      # shallow
b.append([5, 6])      # only affects b
b[0].append(99)       # affects a[0] too — shared reference
print(a)              # [[1, 2, 99], [3, 4]]
```

Shallow copy is O(n) where n is the top-level size. It is appropriate when the elements themselves are immutable (lists of strings, lists of ints) or when you intentionally want to share the nested objects.

**Deep copy** (`copy.deepcopy(a)`) recursively traverses the entire object graph, creating new copies of every nested object. Mutations to any level of `b` do not affect `a`.

```python
b = copy.deepcopy(a)
b[0].append(99)
print(a)  # [[1, 2], [3, 4]] — unaffected
```

Deep copy handles cycles via a memo dict (the second optional argument) that tracks already-copied objects, preventing infinite recursion.

Deep copy is significantly more expensive — O(n) across the entire object graph, with overhead for memo tracking and object reconstruction. It also requires objects to be copyable; some objects (open file handles, database connections, locks) cannot be meaningfully deep-copied and will raise or produce incorrect results.

**Custom behavior:** Classes can control copy behavior by implementing `__copy__` and `__deepcopy__` methods. This is important for objects with external resources or identity requirements.

**Practical guidance:** Use shallow copy when your container holds immutable elements or shared references are intentional. Use deep copy when you need true independence between the copy and the original — for example, when passing a mutable config dict to a function that might modify it, or when implementing undo/redo with state snapshots. Always profile deep copy on large object graphs — it can be a performance bottleneck.

Question 14

What is the difference between __new__ and __init__?

Accepted Answer

Object creation in Python is a two-step process mediated by `__new__` and `__init__`.

`__new__(cls, *args, **kwargs)` is a static method (special-cased by Python) that is responsible for **allocating and returning a new instance**. It receives the class as its first argument and should return an instance of that class (or a different class, which bypasses `__init__`). `object.__new__(cls)` is the default implementation — it allocates memory for the new object.

`__init__(self, *args, **kwargs)` receives the **already-allocated instance** as `self` and is responsible for **initializing its state**. It must return `None`. It is called only if `__new__` returns an instance of `cls` (or a subclass).

The call sequence when you write `Foo(1, 2)`:
1. Python calls `Foo.__new__(Foo, 1, 2)`
2. If the result is an instance of `Foo`, Python calls `result.__init__(1, 2)`
3. The instance is returned to the caller

**When to override `__new__`:**

*Immutable type subclassing:* Immutable types like `int`, `str`, and `tuple` have their value baked in at allocation time. `__init__` is too late to change the value. To customize their construction, you must override `__new__`:

```python
class PositiveInt(int):
    def __new__(cls, value):
        if value <= 0:
            raise ValueError('Must be positive')
        return super().__new__(cls, value)
```

*Singleton pattern:*

```python
class Singleton:
    _instance = None
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance
```

*Metaclasses and class creation:* Metaclasses override `__new__` to control how class objects themselves are created.

*Object deserialization:* `pickle` and `copy` can call `__new__` without `__init__` to reconstruct objects without re-running initialization logic.

**The critical rule:** If `__new__` returns an instance that is NOT an instance of `cls`, `__init__` is not called. This allows factory-like behavior where `__new__` returns different types based on arguments.

For regular mutable classes, override only `__init__`. Overriding `__new__` on a normal class is a code smell unless you have a specific reason.

Question 15

How does Python manage memory with garbage collection and reference counting?

Accepted Answer

CPython uses two complementary mechanisms for memory management: **reference counting** as the primary strategy and a **cyclic garbage collector** as a fallback for cyclic references that reference counting cannot handle.

**Reference Counting**

Every Python object has a reference count stored in its header (`ob_refcnt`). When a name is bound to an object, the count increments. When the binding is removed (variable goes out of scope, `del`, reassignment, collection modified), the count decrements. When the count reaches zero, the object is immediately deallocated — its `__del__` finalizer is called (if defined) and memory is returned to Python's memory allocator.

Advantages: deterministic destruction (objects are freed immediately when no longer reachable), simple implementation, low overhead for non-cyclic object graphs.

Disadvantage: **cyclic references cannot be freed by reference counting alone.** Two objects pointing to each other maintain a count of at least 1 even when no external references exist.

**Cyclic Garbage Collector (`gc` module)**

The `gc` module implements a generational collector that runs periodically to detect and break reference cycles. Objects are tracked in three generations (0, 1, 2). New objects start in generation 0. Objects that survive a collection are promoted to the next generation. Collection frequency decreases for higher generations (heuristic: older objects are less likely to be garbage).

The collector uses a mark-and-sweep variant: it traverses all tracked objects, decrements a copy of their reference counts for internal links (without affecting actual counts), and any object whose copy reaches zero has no external references — it is garbage. Cycles are then broken by clearing internal references before deallocation.

The GC only tracks **container objects** (lists, dicts, class instances, etc.) — not simple objects like integers or strings, which cannot participate in cycles.

**The GIL's role:** The Global Interpreter Lock serializes access to reference counts in CPython, preventing data races on `ob_refcnt` in multi-threaded code. This means reference count operations are thread-safe without per-object locking, but it also means only one thread runs Python bytecode at a time.

**Practical implications:** `gc.disable()` turns off the cyclic collector but not reference counting — useful in performance-critical, cycle-free code. `gc.collect()` triggers a manual collection. `weakref` breaks cycles intentionally by not incrementing reference counts. `__del__` finalizers on objects in cycles historically complicated collection (Python 3.4+ resolved most of this with PEP 442).

Question 16

What is a decorator factory and when would you use one?

Accepted Answer

A decorator is a function that takes a function and returns a modified function. A **decorator factory** is a function that takes arguments and *returns* a decorator. It adds one layer of nesting to allow the decorator to be parameterized.

Without a factory, a decorator is applied as `@my_decorator`. To pass arguments, you'd want `@my_decorator(arg1, arg2)`. This syntax requires `my_decorator(arg1, arg2)` to be called first, returning a decorator—that's a factory.

The structure:

```python
def repeat(n):          # factory — takes arguments
    def decorator(func):  # actual decorator — takes function
        def wrapper(*args, **kwargs):
            for _ in range(n):
                func(*args, **kwargs)
        return wrapper
    return decorator

@repeat(3)
def greet(name):
    print(f'Hello, {name}')
```

Here `repeat(3)` is called at decoration time, returning `decorator`, which then wraps `greet`. The `n=3` is captured in the closure of `wrapper`.

The extra function level (factory → decorator → wrapper) is always the pattern. The factory receives configuration; the decorator receives the function; the wrapper receives call-time arguments.

When to use a decorator factory: any time you want the decorator's behavior to be configurable per use-site—retry count (`@retry(max_attempts=3)`), cache TTL (`@cache(ttl=60)`), required permissions (`@require_role('admin')`), rate limit per endpoint (`@rate_limit(calls=100, period=60)`).

`functools.wraps` should always be applied to the wrapper to preserve the original function's `__name__`, `__doc__`, and `__wrapped__` attribute—without it, introspection and stack traces show `wrapper` instead of the original function name, making debugging painful.

A common pattern is making the factory optional (supporting both `@my_decorator` and `@my_decorator(arg)`), which requires checking whether the argument to the factory is callable—but this adds complexity and is usually not worth it outside library code.

Question 17

What is the difference between __getattr__ and __getattribute__?

Accepted Answer

`__getattribute__` and `__getattr__` are both attribute access hooks, but they differ fundamentally in when they are called and how dangerous they are to override.

**`__getattribute__`** is called on *every* attribute access—`obj.x` unconditionally invokes `type(obj).__getattribute__(obj, 'x')`. It's the lowest-level hook in Python's attribute lookup machinery. Overriding it gives you total control over attribute resolution. The danger: any attribute access inside `__getattribute__` itself (including `self.anything`) recursively calls `__getattribute__` again, causing infinite recursion unless you bypass it with `object.__getattribute__(self, name)`. This makes it very easy to write buggy code. Override it only when you need to intercept all attribute access—e.g., read-tracking, transparent proxies, ORM query builders.

**`__getattr__`** is called only when the normal attribute lookup chain fails—i.e., the attribute wasn't found in the instance's `__dict__`, the class, or any base class. It's a fallback hook, not an interception hook. This makes it safe and idiomatic: overriding it adds dynamic attribute behavior without interfering with normal attributes.

Common use cases for `__getattr__`: providing dynamic attributes based on naming conventions (e.g., `obj.get_field_name()` on a dynamic schema), lazy-loading expensive attributes, implementing proxy objects that forward attribute accesses to a wrapped object, and fluent builder patterns.

Example:

```python
class DynamicProxy:
    def __init__(self, target):
        object.__setattr__(self, '_target', target)  # bypass __setattr__
    
    def __getattr__(self, name):  # only called if normal lookup fails
        return getattr(self._target, name)
```

Note: even setting `self._target` in `__init__` must use `object.__setattr__` if you've also overridden `__setattr__`, or you risk infinite recursion.

The lookup order matters: `__getattribute__` → instance `__dict__` → class `__dict__` → base class MRO → `__getattr__`. Raising `AttributeError` inside `__getattribute__` triggers `__getattr__` as a fallback.

Question 18

What is functools.partial and when would you use it?

Accepted Answer

`functools.partial` is a higher-order function that creates a new callable with some arguments of an existing function pre-filled (partially applied). Calling the resulting partial object supplies the remaining arguments.

Basic usage:

```python
from functools import partial

def power(base, exponent):
    return base ** exponent

square = partial(power, exponent=2)
cube = partial(power, exponent=3)

square(5)  # 25
cube(4)    # 64
```

The `partial` object stores a reference to the original function, the pre-filled positional args, and keyword args. When called, it merges the stored args with the new args and invokes the original function.

**When to use it**:

1. **Callback adaptation**: When a callback signature is fixed (e.g., `button.on_click(callback)` expects `callback(event)`) but you need to pass extra context. `partial(handler, user_id=current_user.id)` creates a bound callback without a lambda.

2. **Creating specialized versions of general functions**: `int_from_hex = partial(int, base=16)` creates a specialized int parser. This is more explicit and picklable than a lambda.

3. **`map`/`filter` integration**: `list(map(partial(operator.mul, 2), [1, 2, 3]))` — more readable than a lambda for simple transformations.

4. **Reducing arity for APIs expecting fewer arguments**: When a library expects a `f(x)` but you have a `g(x, config)` and want to pin `config`.

**Partial vs. lambda**: Both achieve partial application. `partial` is preferred when: the function is already named (no anonymous behavior), the result needs to be picklable (lambdas aren't—`partial` objects are), and introspection matters (`partial` preserves `func`, `args`, `keywords` attributes). Lambdas are better for one-line transformations that benefit from inline readability.

`functools.partialmethod` is the class-method equivalent—used when you want to create a method on a class with some arguments pre-bound, useful for creating specialized versions of base class methods.

Question 19

What are defaultdict and OrderedDict and when would you use them?

Accepted Answer

`defaultdict` and `OrderedDict` are both subclasses of `dict` in `collections`, each adding a specialized behavior on top of the standard dictionary.

**`defaultdict`** takes a *default_factory* callable as its first argument. When you access a key that doesn't exist, instead of raising `KeyError`, it calls `default_factory()` to create a default value, inserts it under that key, and returns it. This eliminates the common `dict.setdefault()` or `if key not in d` boilerplate.

Common default factories:
- `defaultdict(list)` — grouping: `d[key].append(item)` works without initializing the list
- `defaultdict(int)` — counting: `d[key] += 1` works without checking if key exists
- `defaultdict(set)` — grouping unique values: `d[key].add(item)`
- `defaultdict(lambda: defaultdict(int))` — nested counting tables

Important nuance: `default_factory` is only invoked by `__missing__`, which is called by `__getitem__`. Using `d.get(key)` does *not* trigger the factory — it returns `None` (or the specified default). This catches people who expect `.get()` to auto-create.

**`OrderedDict`** preserves insertion order and exposes `move_to_end(key, last=True)` to move a key to the beginning or end. In Python 3.7+, the built-in `dict` also preserves insertion order as a language guarantee (not just an implementation detail). This makes `OrderedDict` less necessary for most use cases.

However, `OrderedDict` still has two advantages: it provides `move_to_end()` for O(1) reordering (implemented as a doubly-linked list), and its `__eq__` considers order—two `OrderedDict`s with the same keys but different insertion order are *not* equal, whereas regular `dict`s consider only key-value pairs.

Practical use: `OrderedDict` as an LRU cache backbone — `move_to_end` on access, `popitem(last=False)` to evict the oldest. This is the pattern Python's `functools.lru_cache` internally mirrors.

Both classes inherit all standard `dict` methods, so they're drop-in replacements where appropriate.

Question 20

What is duck typing in Python?

Accepted Answer

Duck typing is a programming style where an object's suitability for a use is determined by the presence of the required methods and attributes, not by its class hierarchy. The name comes from the phrase: "If it walks like a duck and quacks like a duck, then it must be a duck."

In statically typed languages like Java, you must declare that a class implements an interface before you can pass it to a function expecting that interface. In Python, no such declaration is needed — if the object has the method the function calls, it works. If it doesn't, a `AttributeError` is raised at the point of the call.

A concrete example: Python's `len()` function works on any object that implements `__len__`. It does not require the object to inherit from a `Sequence` base class. A custom class with `__len__` defined is fully compatible. Similarly, any object implementing `__iter__` and `__next__` can be used in a `for` loop — no base class required.

Duck typing enables highly flexible and composable code. The `sorted()` built-in works on any iterable; `json.dump()` accepts any file-like object with a `write()` method; context managers work for any object implementing `__enter__` and `__exit__`. This is why Python's standard library APIs are so interoperable with user-defined types without requiring inheritance.

The trade-off is that type errors are deferred to runtime. A wrong argument type passes undetected until the missing method is called — potentially deep in a call stack with a confusing error message. **Type hints** (PEP 484, Python 3.5+) and static analysis tools like `mypy` and `pyright` address this by adding optional static type checking without changing runtime behavior. **Protocols** (PEP 544, Python 3.8+) formalize duck typing: a `Protocol` class defines the required interface structurally, and `mypy` checks conformance without requiring inheritance — this is called **structural subtyping**.

Duck typing is distinct from inheritance-based polymorphism. With inheritance, you declare the relationship upfront. With duck typing (and Protocols), the relationship is implicit and checked by behavior.

Question 21

What is monkey patching and what are the risks?

Accepted Answer

Monkey patching is the practice of dynamically modifying or replacing attributes, methods, or modules at runtime — without altering the original source code. In Python, because everything is an object and objects are mutable, this is syntactically trivial: you assign a new function to an attribute of a class or module, and all subsequent calls to that attribute invoke your replacement.

The most common legitimate use is **test mocking**. Rather than making a real HTTP request in a unit test, you replace `requests.get` with a function that returns a fixed response: `requests.get = lambda url, **kw: MockResponse(200, data)`. The `unittest.mock.patch` decorator and context manager automate this pattern and restore the original after the test block exits, preventing test pollution.

Another use is **hotfixing third-party libraries** when you cannot wait for an upstream release — you override a buggy method on an imported class at application startup. This is risky and should be temporary.

The risks are substantial. **Hidden coupling**: code that reads the patched attribute has no knowledge of the substitution. If the patch is applied globally (not scoped to a test), all code in the process is affected. **Ordering dependency**: the patch must be applied before any code imports and caches a reference to the original; `from module import func` captures the original reference, bypassing a later `module.func = new_func` patch — a common source of confusing test failures. **Debugging difficulty**: a patched attribute does not appear in the class definition, making tracing broken behavior hard. **Fragility**: if the library being patched is updated and changes the patched method's signature, the patch silently continues with a mismatched interface.

In testing, `unittest.mock.patch` is the correct tool — it restores originals automatically, scopes the patch properly, and provides assertion capabilities. For production code, dependency injection is almost always a better alternative: pass the dependency as an argument rather than patching it globally. This makes the dependency explicit, testable, and auditable in code review.

Question 22

What are mixins and how do they differ from regular inheritance?

Accepted Answer

A mixin is a class that provides specific, reusable behavior intended to be 'mixed in' to other classes via multiple inheritance, without being instantiated directly or expressing an 'is-a' relationship. Mixins bundle a coherent set of methods that augment a target class, keeping concerns separated and reducing code duplication without creating deep inheritance hierarchies.

The key distinction from regular inheritance is **intent and coupling**. In classical inheritance, `Dog(Animal)` means a Dog *is an* Animal — the relationship is semantic and the parent class is typically a meaningful standalone entity. A mixin like `JSONSerializableMixin` does not make semantic sense on its own; it only exists to add `to_json()` and `from_json()` methods to whatever class uses it. A mixin typically:
- Does not call `__init__` (or delegates to `super().__init__()`);
- Does not have meaningful state of its own (or only adds specific attributes);
- Is never instantiated directly;
- Depends on the host class providing certain attributes or methods it uses.

In Python, mixins are implemented via multiple inheritance. Python's **MRO (Method Resolution Order)** uses the C3 linearization algorithm to determine method lookup order when a class inherits from multiple bases. The convention is to list mixin classes before the primary base class: `class MyView(LoginRequiredMixin, View)`. MRO processes left to right, depth-first with linearization, so `LoginRequiredMixin.dispatch()` is found before `View.dispatch()`. Django's class-based views are the canonical Python example of mixin composition.

Mixins call `super()` to pass control up the MRO chain, enabling **cooperative multiple inheritance** — each mixin in the chain gets a chance to contribute its behavior. This is more powerful but requires that all classes in the chain use `super()` consistently.

The risks are MRO complexity in deep hierarchies, implicit dependencies between mixins and host classes (duck-typed attribute assumptions), and the possibility of conflicting method names. Protocols (Python 3.8+) and composition over inheritance are alternatives that make dependencies explicit, but mixins remain idiomatic in Django and other Python frameworks.

Question 23

How do you profile Python code with cProfile?

Accepted Answer

Profiling is the process of measuring where a program spends its time, so you can direct optimization efforts at the actual bottleneck rather than guessing. Python's built-in `cProfile` module is a deterministic profiler that instruments every function call and records call counts, total time, and cumulative time per function.

The simplest usage is from the command line: `python -m cProfile -s cumulative my_script.py`. The `-s cumulative` flag sorts output by cumulative time — time spent in a function *including* all callees. This is usually the most useful sort for finding the root of slowness. Other sort keys: `tottime` (time in the function excluding callees — useful for finding tight CPU loops), `ncalls` (call frequency), `filename`.

From within code, you wrap the target section:
```python
import cProfile
with cProfile.Profile() as pr:
    result = expensive_function()
pr.print_stats(sort='cumulative')
```

For programmatic analysis, dump to a file and load with `pstats`:
```python
pr.dump_stats('output.prof')
import pstats
stats = pstats.Stats('output.prof')
stats.strip_dirs().sort_stats('cumulative').print_stats(20)
```
`strip_dirs()` removes path prefixes for cleaner output; `print_stats(20)` shows only the top 20 functions.

For visualization, **snakeviz** (`pip install snakeviz; snakeviz output.prof`) renders an interactive sunburst chart of the call tree in a browser — far easier to navigate than raw text for large profiles. **gprof2dot** generates call-graph DOT files.

cProfile has overhead because it instruments *every* function call — typically 10-50x slowdown. For production profiling of a live service, **py-spy** is a sampling profiler that attaches to a running process without modification or restart, reads the Python stack via ptrace, and produces flamegraphs with minimal overhead.

Profile the *same workload* you are optimizing — synthetic microbenchmarks often mislead. Use `timeit` for isolated micro-benchmarks of specific expressions. For memory profiling (not CPU), use `memory_profiler` or `tracemalloc` (built-in since Python 3.4).

Question 24

What are the most useful itertools functions and when do you use them?

Accepted Answer

The itertools module provides building blocks for efficient looping in Python, operating lazily so they never materialize full sequences in memory.

**chain(*iterables)** concatenates multiple iterables as if they were one. Use it when you have several lists or generators to process sequentially without combining them first.

**islice(iterable, stop)** slices a potentially infinite or large iterable without consuming it. It is the correct way to take the first N items from a generator.

**groupby(iterable, key)** groups consecutive elements that share a key. The critical gotcha: the input must be sorted on the same key first, otherwise non-consecutive equal-key items form separate groups.

**product(*iterables)** produces the Cartesian product — equivalent to nested for-loops. Useful for generating test parameter combinations or grid searches without nesting.

**combinations(iterable, r)** and **permutations(iterable, r)** generate combinatorial subsets. combinations does not repeat elements and ignores order; permutations produce all orderings.

**cycle(iterable)** and **repeat(object, times)** create infinite or controlled repetitions. Pair cycle with islice when you need round-robin assignment over a fixed pool.

**accumulate(iterable, func)** computes running aggregates — running sum, running max — without writing an explicit loop variable.

**takewhile(pred, iterable)** and **dropwhile(pred, iterable)** split a sequence at the first point a predicate changes value. Use them to parse line-oriented formats where a header section ends at a blank line.

The practical interview point: prefer itertools over list comprehensions when dealing with large data pipelines. Chaining several itertools operations avoids O(n) intermediate allocations at each step, which matters for gigabyte-scale data or streaming inputs.

Question 25

How do pytest fixtures, mocking, and patching work?

Accepted Answer

**Fixtures** are functions decorated with `@pytest.fixture` that pytest injects into test functions by parameter name. They handle setup and teardown via yield: code before yield runs before the test, code after yield runs after it regardless of outcome. Fixtures have scopes — function (default, re-created each test), class, module, session — that control how often the fixture is instantiated. Session-scoped fixtures are ideal for expensive resources like database connections. Fixtures can depend on other fixtures, letting you compose complex setups from small pieces. conftest.py files make fixtures available across a directory tree without explicit imports.

**Mocking** replaces real objects with `MagicMock` or `AsyncMock` instances that record calls and return configurable values. You create a mock, configure `mock.return_value` or `mock.side_effect`, pass it into the code under test, then assert on `mock.called`, `mock.call_args`, or `mock.call_count`.

**Patching** is how you inject mocks into code that creates its own dependencies internally. `unittest.mock.patch` temporarily replaces a name in a specific module's namespace. The key rule: patch where the name is looked up, not where it is defined. If `myapp.service` imports `requests` and uses `requests.get`, you patch `myapp.service.requests.get`, not `requests.get`.

patch can be used as a decorator, a context manager, or called manually with start/stop. The `pytest-mock` library exposes a `mocker` fixture that provides `mocker.patch()` with automatic teardown, which is cleaner than decorator stacking.

`side_effect` is more powerful than `return_value`: it can be a list of successive return values, an exception class to raise, or a callable that inspects arguments. Use side_effect when the mock needs to behave differently across calls or simulate failures.

For async code, use `AsyncMock` (Python 3.8+) so that awaiting the mock works correctly. A regular `MagicMock` used as a coroutine will raise a TypeError.

Question 26

What are code coverage and static analysis tools and why are they useful?

Accepted Answer

**Code coverage** quantifies how much of your source code is exercised by a test suite. The standard Python tool is `coverage.py`, typically invoked via `pytest --cov`. It instruments the bytecode to track which lines execute. The report shows line coverage (percentage of lines hit) and optionally branch coverage (whether both sides of every conditional were reached). Branch coverage is strictly more informative because 100% line coverage can still miss the false branch of an `if` statement.

Coverage percentage is a proxy metric, not a quality metric. High coverage with weak assertions proves nothing. The useful workflow is to run coverage after adding tests, look at the HTML report to find uncovered branches, and add targeted tests for logic paths that represent real risk.

**Static analysis** inspects source code without executing it. Tools fall into several categories:

- **Style / formatting**: `flake8` (PEP 8 violations), `black` (opinionated auto-formatter), `isort` (import ordering). These are zero-configuration in CI.
- **Type checking**: `mypy` and `pyright` analyze type annotations to catch type errors before runtime. They are most valuable in large codebases where function signatures would otherwise be implicit.
- **Security scanning**: `bandit` flags common security issues — hardcoded passwords, use of eval, insecure hash algorithms.
- **Complexity**: `radon` or `flake8-cognitive-complexity` measure cyclomatic complexity per function. High complexity correlates with bug density and difficulty of testing.

In a modern Python project, these tools run together in CI: black and isort in check mode for formatting, flake8 or ruff for lint, mypy for type checking, and coverage after the test run. `ruff` is increasingly popular because it replaces flake8, isort, and several plugins with a single fast Rust-based tool.

The interview-relevant distinction: coverage tells you what was executed; static analysis tells you what is wrong before execution. Both are complementary, not substitutes.

Question 27

How do Poetry, PyPI, and virtualenv relate in Python package management?

Accepted Answer

**PyPI** (Python Package Index) is the public registry of Python packages. When you run `pip install requests`, pip fetches the package from PyPI. Packages are uploaded to PyPI by maintainers in wheel or source-distribution format.

**virtualenv** (and its stdlib equivalent `venv`) creates an isolated Python environment with its own site-packages directory. This prevents packages installed for one project from affecting another and ensures reproducibility. Activating a virtualenv rewrites PATH so that `python` and `pip` resolve to the environment's binaries.

**pip** is the default installer — it resolves and installs packages from PyPI but has historically had weak dependency resolution. `pip freeze > requirements.txt` captures exact versions; `pip install -r requirements.txt` restores them. The weakness is that requirements.txt does not distinguish direct from transitive dependencies.

**Poetry** is a higher-level tool that unifies dependency management, virtual environment creation, and package publishing. It uses `pyproject.toml` (the modern PEP 517/518 standard) to declare direct dependencies with version constraints, and `poetry.lock` to pin the full transitive closure of the dependency graph. The lock file is deterministic — any developer or CI job installing from the same lock file gets identical package versions.

Poetry's key commands: `poetry add <pkg>` updates pyproject.toml and resolves the lock file; `poetry install` installs everything from the lock file; `poetry run` executes commands inside the managed environment without explicit activation; `poetry publish` packages and uploads to PyPI.

The relationship: Poetry still pulls packages from PyPI using pip-compatible infrastructure, and it still creates a virtualenv under the hood. It adds the lock file, the unified workflow, and the separation of dev dependencies (`poetry add --group dev pytest`).

For teams, Poetry (or its alternative Hatch/PDM) is preferred over raw pip because the lock file eliminates the 'works on my machine' class of bugs caused by transitive dependency drift.

Question 28

What is the difference between modules and packages? What does __init__.py do?

Accepted Answer

A **module** in Python is any single `.py` file. When you write `import utils`, Python finds `utils.py` on the module search path (`sys.path`) and executes it, caching the result in `sys.modules`. The module's top-level names become attributes on the imported object.

A **package** is a directory that contains one or more modules. What makes it a package rather than a plain directory is the presence of an `__init__.py` file. When Python encounters `import mypackage`, it executes `mypackage/__init__.py` and treats its namespace as the package's namespace.

**What `__init__.py` does:**

1. **Marks the directory as a package** — without it, Python 2 would not recognize the directory as importable. In Python 3.3+, namespace packages allow directories without `__init__.py`, but regular packages with it are still the standard.
2. **Controls the public API** — you import and expose names here so consumers can write `from mypackage import MyClass` instead of `from mypackage.submodule import MyClass`. This decouples internal structure from external interface.
3. **Runs initialization code** — database connections, plugin registration, or configuration loading at import time. Keep this minimal to avoid slow imports.
4. **Defines `__all__`** — a list of names that `from mypackage import *` will export. Without `__all__`, star imports export everything not prefixed with an underscore.

**Relative imports** use dot notation to refer to siblings within the same package: `from . import sibling` or `from ..parent import thing`. They only work inside a package, not in top-level scripts.

A **namespace package** (PEP 420) is a package spread across multiple directories with no `__init__.py`, useful for plugin systems or splitting a large package across repositories. Python merges the directories into a single package namespace.

The practical impact: well-structured `__init__.py` files let you refactor internal module organization without breaking external imports, because consumers import from the package, not the internal file path.

Python Interview Questions — What Senior Engineers Need to Know

All 28 Questions

How to Prepare

Related Topics

Test Your Knowledge