Python Fundamentals Interview Questions

Both are ordered sequences, but a list (`[]`) is mutable -- you can add, remove, or change elements -- while a tuple (`()`) is immutable once created.

`==` compares whether two objects have equal values; `is` compares whether two names refer to the exact same object in memory. Two equal-valued objects can still be `is not` each other.

Common mistake: Using `is` to compare values (e.g. `x is 5`) instead of `==`, which can behave inconsistently depending on Python's internal integer caching.

Mutable: `list`, `dict`, `set`. Immutable: `int`, `float`, `str`, `tuple`, `frozenset`, `bool`.

Python uses consistent indentation (whitespace) to delimit blocks, rather than braces -- inconsistent indentation within the same block is a syntax error, not just a style issue.

A concise expression for building a new list -- `[x * 2 for x in nums if x > 0]` -- that's typically more readable and often faster than the equivalent explicit loop with repeated `.append()` calls.

squares = [n ** 2 for n in range(5)]
# [0, 1, 4, 9, 16]

`range(5)` is a lazy, memory-efficient sequence object that generates values on demand as you iterate; it doesn't store all values in memory up front the way a real list does.

`and`/`or` return one of the actual operand values (short-circuiting), not necessarily a boolean -- `"" or "default"` returns `"default"`, and `5 and 10` returns `10`.

Slicing (`text[start:stop:step]`) extracts a substring/subsequence; `text[::-1]` uses a step of `-1` with default start/stop, walking the string backward from end to start.

An f-string (`f"Hello, {name}!"`) embeds expressions directly inside string literals, evaluated at runtime -- generally more readable and slightly faster than older `.format()` or `%`-style formatting.

It assigns a value to a name as part of a larger expression, letting you both compute and reuse a value inline -- e.g. `if (n := len(data)) > 10:` assigns `n` and checks it in one line.

`*args` collects extra positional arguments into a tuple; `**kwargs` collects extra keyword arguments into a dictionary -- both let a function accept a flexible number of arguments.

def greet(*args, **kwargs):
    print(args, kwargs)

greet(1, 2, name="Asha")
# (1, 2) {'name': 'Asha'}

Default argument values are evaluated once, when the function is defined, not on every call -- so a mutable default is shared and accumulates state across every call that doesn't pass its own value.

Common mistake: Using `def add_item(item, bucket=[]):` and being surprised the same list keeps growing across unrelated calls.

An anonymous, single-expression function (`lambda x: x * 2`), appropriate for short throwaway logic like a `sorted()` key function -- generally not used for anything requiring multiple statements or a meaningful name.

A function that wraps another function to add behavior (logging, timing, access control) without modifying the wrapped function's own code, applied with `@decorator_name` syntax above a function definition.

`None` -- a Python function that runs to completion without an explicit `return value` (or with a bare `return`) implicitly returns `None`.

Python resolves a name by checking, in order: Local (current function), Enclosing (any outer function), Global (module level), then Built-in -- the first scope where the name is found wins.

It tells Python that an assignment inside the function should modify the module-level variable of that name, rather than creating a new local variable that shadows it.

A generator function uses `yield` to produce a sequence of values lazily, pausing its state between each value instead of computing them all up front and exiting like `return` does -- useful for large or infinite sequences.

A string literal placed as the first statement in a module, function, class, or method (`"""Explains what this does."""`), accessible at runtime via `.__doc__` and used by documentation/help tools -- unlike `#` comments, which are stripped entirely and unavailable at runtime.

Type hints (`def add(a: int, b: int) -> int:`) document expected types for readability and static-analysis tools like `mypy`, but Python itself does not enforce or check them at runtime by default.

A `list` is an ordered sequence indexed by position (`0, 1, 2, ...`); a `dict` is an unordered-by-default (though insertion-order-preserving since Python 3.7) collection of key-value pairs indexed by arbitrary hashable keys.

An unordered collection of unique, hashable elements -- useful for removing duplicates from a sequence and for fast membership testing (`x in my_set` is roughly O(1) versus O(n) for a list).

Use `d.get(key, default)`, which returns the default instead of raising a `KeyError` -- as opposed to `d[key]`, which raises if the key is missing.

A concise syntax for building a dict from an iterable -- `{k: v * 2 for k, v in prices.items()}` -- analogous to list comprehensions but producing key-value pairs.

Dictionary keys must be hashable, and hashability generally requires immutability -- tuples are immutable (and hashable, if their elements are too), while lists are mutable and therefore unhashable.

It yields `(index, value)` pairs, letting you access both the position and the value in a `for` loop without manually tracking a counter -- `for i, item in enumerate(items):`.

It pairs up corresponding elements from multiple iterables into tuples, stopping at the shortest input -- `zip([1, 2], ["a", "b"])` produces `(1, "a"), (2, "b")`.

List membership is O(n) (it may scan every element); set membership is average-case O(1), because sets are backed by a hash table -- this matters for performance on large collections checked repeatedly.

Python evaluates the right-hand side tuple `(b, a)` fully before assigning, then unpacks it into `a, b` in order -- so the swap happens in one step without needing an explicit temp variable.

A package is a directory containing an `__init__.py` (or, in modern Python, optionally just a namespace package) that groups related modules together under a shared importable name, e.g. `import mypackage.submodule`.

`with open(path) as f:` guarantees the file is closed automatically once the block exits, even if an exception is raised inside it -- manual `open()`/`close()` risks leaking the file handle if an error occurs before `close()` runs.

Common mistake: Manually calling open()/close() without a try/finally, leaking a file handle when an exception occurs between them.

`except Exception:` catches standard runtime errors but lets low-level system-exit signals (like `KeyboardInterrupt` or `SystemExit`) propagate; a bare `except:` catches literally everything, including those, which can make a program impossible to interrupt cleanly.

Common mistake: Using a bare except: that silently swallows KeyboardInterrupt, making the running script impossible to Ctrl+C out of.

Code inside `finally` always runs, whether or not an exception occurred (and even if the `try` or `except` block returns) -- typically used for cleanup like closing a resource.

`__new__` actually creates and returns a new instance (rarely overridden); `__init__` receives that already-created instance (`self`) and initializes its attributes -- `__init__` doesn't create the object, it configures it.

Inheritance lets a class (subclass) reuse and extend another class's (parent's) behavior. You typically call the parent's constructor with `super().__init__(...)` inside the subclass's own `__init__`.

A class attribute is defined directly on the class body and shared across all instances (unless overridden); an instance attribute is set per-object, typically inside `__init__` via `self.attr = value`.

Common mistake: Using a mutable class attribute (like a list) expecting each instance to have its own copy, when all instances actually share the same object.

`__str__` controls the readable, user-facing string returned by `str(obj)`/`print(obj)`; `__repr__` controls the unambiguous, developer-facing representation shown in a REPL or by `repr(obj)`, ideally detailed enough to help debugging.

Automated tests are repeatable, fast to re-run after every change, and catch regressions immediately -- manual eyeballing doesn't scale as a codebase grows and doesn't leave a record that a given behavior was verified.

Subclassing `Exception` (e.g. `class InsufficientFundsError(Exception): pass`) lets calling code catch and handle a specific, meaningful failure mode distinctly from generic errors, rather than parsing a generic exception's message string.

A unit test verifies one small piece of code (a function or method) in isolation, often with dependencies mocked; an integration test verifies that multiple real pieces (e.g. a function and a real database) work correctly together.

An isolated, project-specific installation of Python packages (created with `python -m venv .venv`), keeping one project's dependencies from conflicting with another's or with system-wide packages.

`pip` is Python's standard package installer; a `requirements.txt` file lists a project's dependencies (often pinned to specific versions) so `pip install -r requirements.txt` can reproduce the same environment elsewhere.

Python's official style guide, covering conventions like naming (`snake_case` for functions/variables), indentation, and line length -- following it makes code more consistent and easier for other contributors to read.

It guards code so it only runs when the file is executed directly, not when it's imported as a module into another file -- letting a file be both a reusable module and a runnable script.

Common mistake: Omitting the __name__ guard, causing top-level script code to run unexpectedly whenever the file is imported elsewhere.

The GIL is a lock in CPython ensuring only one thread executes Python bytecode at a time, meaning CPU-bound work doesn't get true parallelism from multiple threads -- CPU-bound parallelism typically requires multiprocessing instead.

Python is a language specification; CPython is the most common implementation of it (written in C) -- other implementations exist (PyPy, Jython), and details like the GIL are specific to CPython, not the language itself.

A syntax error is caught before the program runs at all, while parsing the code; a runtime exception (like `ZeroDivisionError` or `KeyError`) occurs while the program is executing, only if that specific line is actually reached.

Pinning versions (e.g. `requests==2.31.0`) ensures every environment installs the exact same dependency code, avoiding bugs caused by an unrelated upstream package update silently changing behavior between installs.

The set of modules bundled with every Python installation (e.g. `os`, `json`, `datetime`, `re`) -- checking it first avoids adding an unnecessary external dependency when built-in functionality already covers the need.

`assert condition` raises an `AssertionError` if the condition is false, but assertions can be globally stripped out when Python runs with optimizations enabled (`-O`), so they're meant for internal invariant checks during development, not for enforcing security-relevant validation.

Common mistake: Using assert to validate untrusted user input in production code, which can be silently disabled when Python runs with optimizations enabled.