Debasis Bhattacharjee

'break' exits the loop entirely. 'continue' skips the current iteration and moves to the next. 'pass' does nothing — it is a placeholder.

Deep Dive: These three keywords control loop flow differently. 'break' immediately terminates the enclosing loop and execution continues after the loop block. 'continue' stops the current iteration and jumps back to the loop condition check. 'pass' is a null operation — it literally does nothing and is used when Python syntax requires a statement but you have no code to put there yet such as in an empty class or function body during development. Misunderstanding these leads to infinite loops or skipped logic in data processing pipelines.

Real-World: In a CSV data cleaning pipeline: 'continue' skips rows with missing values 'break' stops processing if a critical error is found in the data and 'pass' is used in an exception handler that acknowledges an error but intentionally takes no action (though this is usually bad practice in production).

⚠ Common Mistakes: Using 'pass' thinking it skips an iteration (it does not — use 'continue'). Using 'break' inside a nested loop thinking it exits all loops (it only exits the innermost one). Leaving 'pass' in production exception handlers silently swallowing errors.

🏭 Production Scenario: A data ingestion job was silently skipping thousands of records because a developer used 'pass' in an exception handler instead of 'continue' combined with logging. The job appeared to complete successfully but the database was missing 30% of expected records.

Follow-up questions: How do you break out of nested loops in Python? What is the for-else construct in Python? How does 'continue' interact with try-except blocks?

// ID: PY-BEG-004  ·  DIFFICULTY: 2/10  ·  ★★☆☆☆☆☆☆☆☆

'self' refers to the specific instance of the class that a method is being called on. It gives each instance access to its own attributes and other methods.

Deep Dive: When you define a method inside a class Python does not automatically know which instance the method is operating on. 'self' is the conventional first parameter that receives a reference to the calling instance. When you call instance.method() Python automatically passes the instance as the first argument — you never pass 'self' explicitly when calling. Without 'self' all instances of a class would share the same state which would make OOP impossible. The name 'self' is a convention not a keyword — you could use any name but deviating from convention is considered bad practice.

Real-World: In a User class for a web application self.username and self.email store per-instance data. When the send_email() method is called on a specific user object 'self' ensures the method sends to that user's email address not to some global or shared value.

⚠ Common Mistakes: Forgetting to add 'self' as the first parameter of an instance method causing a TypeError when called. Confusing instance methods (use self) with class methods (use cls) and static methods (use neither). Thinking 'self' is a keyword like 'this' in Java.

🏭 Production Scenario: A production multi-tenant SaaS application had a bug where all tenants were seeing the same configuration because a developer defined tenant settings as class-level attributes instead of instance attributes set via self. Every update to one tenant's config overwrote all others.

Follow-up questions: What is the difference between instance attributes and class attributes? What is @classmethod versus @staticmethod? Can you call a method without an instance using the class directly?

// ID: PY-BEG-005  ·  DIFFICULTY: 2/10  ·  ★★☆☆☆☆☆☆☆☆

F-strings (formatted string literals) are the modern Python way to embed expressions inside strings using f'text {expression}'. They are faster more readable and less error-prone than % formatting or str.format().

Deep Dive: Introduced in Python 3.6 f-strings evaluate expressions inside curly braces at runtime. The 'f' prefix before the quote tells Python to treat the string as a formatted literal. You can embed any valid Python expression: variables arithmetic function calls method calls conditional expressions. They are the fastest string formatting method in Python — benchmarks show f-strings are 40-70% faster than str.format() and significantly faster than % formatting because the expression evaluation happens at the bytecode level. Python 3.12 added even more f-string capabilities including reusing quote types inside expressions.

Real-World: In a web application logging system f-strings make log messages clear and fast: f'User {user.id} ({user.email}) performed {action} on resource {resource_id} at {timestamp}' — includes no string concatenation and is immediately readable during log review.

⚠ Common Mistakes: Using string concatenation with + instead of f-strings in high-frequency code paths. Forgetting that curly braces must be escaped as {{ and }} if you want literal braces. Using f-strings in logging calls when the string might never be formatted (use lazy % formatting for log messages to avoid building strings that are never logged at the configured log level).

🏭 Production Scenario: A high-throughput data processing service was building millions of formatted strings per hour using str.format(). Profiling showed string formatting as a significant CPU cost. Switching to f-strings reduced the formatting overhead by 45% contributing to a measurable throughput improvement.

Follow-up questions: What are the format specification mini-language options available in f-strings? How do f-strings handle multi-line expressions? What changed in Python 3.12 regarding f-strings?

// ID: PY-BEG-007  ·  DIFFICULTY: 2/10  ·  ★★☆☆☆☆☆☆☆☆

Lists are mutable (changeable); tuples are immutable (fixed). Use tuples for data that should not change.

Deep Dive: In Python, a list is defined with square brackets [] and can be modified after creation — you can append, remove, or change elements. A tuple is defined with parentheses () and cannot be modified after creation. This immutability makes tuples slightly faster and hashable, meaning they can be used as dictionary keys or set members. Python internally optimizes tuple storage so they consume less memory than equivalent lists. The immutability also serves as a signal to other developers that this data is not meant to change.

Real-World: A Django settings file uses tuples for ALLOWED_HOSTS and INSTALLED_APPS because these values should be fixed at configuration time. Using a list there would work but signals the wrong intent to maintainers.

⚠ Common Mistakes: Using a list when the data never changes (wastes memory and loses semantic meaning). Trying to modify a tuple and getting a TypeError without understanding why. Forgetting that a tuple with one element needs a trailing comma: (42,) not (42).

🏭 Production Scenario: A production API was returning inconsistent responses because a developer accidentally appended to what should have been a fixed configuration list. Switching to a tuple made the bug immediately visible as a TypeError on the next attempted modification.

Follow-up questions: Can a tuple contain mutable objects? What is the performance difference between list and tuple iteration? When would you use a named tuple?

// ID: PY-BEG-001  ·  DIFFICULTY: 2/10  ·  ★★☆☆☆☆☆☆☆☆

'==' checks value equality. 'is' checks identity — whether two variables point to the exact same object in memory.

Deep Dive: The == operator calls the __eq__ method and compares values. The 'is' operator compares object identity using id(). Two objects can be equal in value but be different objects in memory. Python caches small integers (-5 to 256) and interned strings which can make 'is' return True unexpectedly for these values leading to subtle bugs if misused. You should almost never use 'is' to compare values — reserve it for None checks (if x is None) where it is both correct and idiomatic.

Real-World: In a user authentication system: 'if user_role == admin_role' correctly compares role names as strings. Using 'is' instead works on small test data due to string interning but silently fails in production when role strings come from a database and are different objects with the same value.

⚠ Common Mistakes: Using 'is' to compare strings or integers expecting value equality. Being confused by small integer caching making 'is' appear to work correctly during testing. Not using 'is None' — using == None instead which is slower and less Pythonic.

🏭 Production Scenario: A production bug was caused by comparing user permission strings with 'is' instead of '=='. Tests passed because short strings were interned but in production with database-fetched strings the comparison always returned False locking all users out of admin features.

Follow-up questions: What is object identity in Python? How does Python intern strings? Why is 'is None' preferred over '== None'?

// ID: PY-BEG-002  ·  DIFFICULTY: 3/10  ·  ★★★☆☆☆☆☆☆☆

*args collects extra positional arguments as a tuple. **kwargs collects extra keyword arguments as a dictionary. Both allow functions to accept a variable number of arguments.

Deep Dive: When you define a function with *args any positional arguments beyond the explicitly defined ones are packed into a tuple called args. With **kwargs any keyword arguments not explicitly defined are packed into a dictionary called kwargs. The names args and kwargs are just convention — the * and ** operators are what matter. You can use *args and **kwargs together and you can also use them when calling functions to unpack sequences and dictionaries into arguments. This pattern is heavily used in decorators, class inheritance, and API wrappers.

Real-World: Django's class-based views use **kwargs extensively to pass URL parameters captured by the router into view methods. FastAPI uses *args and **kwargs in middleware to forward requests without knowing the exact signature of the next handler.

⚠ Common Mistakes: Confusing *args (tuple) with a list. Forgetting that *args must come before **kwargs in the function signature. Trying to access args by keyword or kwargs by position. Mutating args thinking it is a list.

🏭 Production Scenario: A logging decorator in a production Flask app broke when a new endpoint added a keyword argument. The fix was changing the decorator to use *args and **kwargs so it would transparently forward any arguments to the wrapped function without needing updates every time a new parameter was added.

Follow-up questions: How does ** unpacking work when calling a function? Can you have both *args and explicit keyword arguments? How are *args and **kwargs used in class __init__ with inheritance?

// ID: PY-BEG-003  ·  DIFFICULTY: 3/10  ·  ★★★☆☆☆☆☆☆☆

'try' runs code that might fail. 'except' catches specific errors. 'finally' always runs regardless of whether an error occurred — used for cleanup.

Deep Dive: The try block contains the risky code. If an exception occurs Python looks for a matching except clause. You can catch specific exception types (except ValueError) or use a bare except to catch everything (not recommended). The else clause (optional) runs only if no exception occurred. The finally clause always executes even if there was an exception or a return statement inside try — making it essential for releasing resources like file handles database connections or locks. Multiple except clauses can handle different exception types differently.

Real-World: In a database write operation: the try block executes the INSERT query the except block catches IntegrityError for duplicate keys and returns a meaningful error message the finally block always closes the database connection regardless of success or failure — preventing connection pool exhaustion.

⚠ Common Mistakes: Using a bare 'except:' that catches everything including KeyboardInterrupt and SystemExit making the program impossible to stop. Not closing resources in finally causing memory or connection leaks. Catching too broad an exception type and hiding real bugs.

🏭 Production Scenario: A production API server ran out of database connections after 6 hours because a developer forgot to close connections in a finally block. The try block opened a connection an exception occurred the connection was never closed and the pool was exhausted within hours under normal traffic.

Follow-up questions: What is the difference between except Exception and bare except? When does finally NOT execute? How do context managers (with statement) relate to try-finally?

// ID: PY-BEG-006  ·  DIFFICULTY: 3/10  ·  ★★★☆☆☆☆☆☆☆

A module is a single .py file containing Python code. A package is a directory containing multiple modules and an __init__.py file. Packages allow organizing related modules into a hierarchical namespace.

Deep Dive: Any .py file is a module — it can be imported with 'import filename'. A package is a directory with an __init__.py file (can be empty) that tells Python to treat the directory as a package. The __init__.py can import from submodules to define the package's public API. Modern Python (3.3+) supports namespace packages — directories without __init__.py — but explicit __init__.py is still preferred for clarity. Import paths follow the directory structure: in a package 'myapp' with a subpackage 'utils' containing 'helpers.py' you import with 'from myapp.utils.helpers import my_function'. The __init__.py content controls what 'from myapp import *' exports.

Real-World: Django is structured as a package: the top-level 'django' directory contains __init__.py and subpackages like 'django.db' 'django.http' 'django.contrib' each have their own __init__.py. This allows clean imports like 'from django.db import models' while keeping the codebase organized across hundreds of files.

⚠ Common Mistakes: Forgetting __init__.py in package directories (causes ImportError in Python 2 sometimes works as namespace package in Python 3 but can cause confusing behavior). Circular imports between modules in the same package. Relative imports (from . import module) vs absolute imports — relative imports can cause issues when running scripts directly.

🏭 Production Scenario: A production Django application was growing to 50+ Python files in a single directory. Refactoring into packages (api/ models/ services/ utils/) with __init__.py files and clean public APIs reduced import statement complexity and made it possible to see the application structure at a glance.

Follow-up questions: What is the __all__ variable in Python modules? How does Python's import system search for modules (sys.path)? What is the difference between 'import module' and 'from module import name'?

// ID: PY-BEG-008  ·  DIFFICULTY: 3/10  ·  ★★★☆☆☆☆☆☆☆

A generator produces items one at a time using lazy evaluation — it only computes each item when requested. A list computes and stores all items immediately. Generators use far less memory for large sequences.

Deep Dive: Generators are created using generator functions (functions with yield instead of return) or generator expressions (like list comprehensions but with parentheses). When you call a generator function it returns a generator object without executing the body. Each call to next() on the generator executes until the next yield pauses execution and returns the value. The generator remembers its state between next() calls. Key advantage: memory. A list of 1 million items stores all 1 million in memory. A generator that yields 1 million items stores only the current item and the execution state. Generators are also composable — you can chain generators to build processing pipelines without intermediate memory allocation.

Real-World: Processing a 10GB log file: reading the entire file into a list would require 10GB of RAM. A generator that yields one line at a time uses constant memory regardless of file size. In data pipelines: file_lines → filter_errors → parse_timestamps → aggregate — each step is a generator passing items to the next without intermediate storage.

⚠ Common Mistakes: Forgetting that a generator is exhausted after iteration — you cannot iterate over it twice. Not recognizing that for loops and many Python builtins (sum list map) accept any iterable including generators. Using a list comprehension when a generator expression would suffice (when you only need to iterate once). Confusing generator functions (use yield) with regular functions that return lists.

🏭 Production Scenario: A data export API was timing out for large datasets because it built a complete list of 500000 records before streaming. Refactoring to yield records one at a time from a generator allowed streaming the response immediately and eliminated the memory spike and timeout.

Follow-up questions: What is the difference between yield and return in a generator? What is yield from and when do you use it? How do you convert a generator to a list and back?

// ID: PY-BEG-009  ·  DIFFICULTY: 3/10  ·  ★★★☆☆☆☆☆☆☆

A list comprehension is a concise way to create lists using a single line expression. Avoid them when the logic is complex enough that a regular loop is more readable.

Deep Dive: List comprehensions follow the syntax [expression for item in iterable if condition]. They are faster than equivalent for loops because they are optimized at the C level in CPython. However they are not always the right choice. Avoid them when: the logic requires multiple nested conditions you need to handle exceptions inside the loop the comprehension spans more than two lines when formatted or you are consuming a large dataset where a generator expression would be more memory-efficient. Nested list comprehensions (list comprehensions inside list comprehensions) are almost always a readability mistake.

Real-World: In a data processing pipeline: [user.email for user in users if user.is_active and user.verified] is clean and appropriate. But building a matrix transformation with three nested comprehensions is a maintainability trap — a regular loop with clear variable names is better for the next developer.

⚠ Common Mistakes: Nesting comprehensions three levels deep making code unreadable. Using list comprehensions when you actually need a generator (you are iterating once over a large dataset). Adding side effects inside comprehensions (modifying external state) which is a major anti-pattern.

🏭 Production Scenario: A memory crash in a production data export service was traced to a list comprehension processing 2 million records at once loading everything into memory. Replacing it with a generator expression fixed the memory issue without changing any other code.

Follow-up questions: What is the difference between a list comprehension and a generator expression? How do dict comprehensions and set comprehensions work? What is the performance difference between a comprehension and a map() call?

// ID: PY-INT-001  ·  DIFFICULTY: 4/10  ·  ★★★★☆☆☆☆☆☆