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

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.

*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.

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.

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

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.

Cross-validation trains and evaluates a model multiple times on different subsets of data giving a more reliable estimate of generalization performance especially for small datasets. The most common form is k-fold cross-validation.

In k-fold cross-validation the dataset is split into k equal parts (folds). The model is trained k times each time using k-1 folds for training and 1 fold for validation. The final performance metric is the average across all k evaluations and you also get a standard deviation showing how stable the model is. Common choices: k=5 (20% validation each time) or k=10 (10% validation). Benefits over single split: uses all data for both training and validation (important for small datasets) provides confidence intervals on performance (single split gives one number — is it lucky or representative?) and reveals if the model is sensitive to which data is in training vs validation (high variance = potential overfitting). Stratified k-fold maintains class proportions in each fold — essential for imbalanced classification.

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.

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.

pytest discovers and runs test functions automatically providing rich assertion introspection fixtures for dependency injection and parametrize for data-driven tests. A good unit test is fast isolated deterministic and tests one specific behavior.

pytest looks for files named test_*.py functions named test_* and classes named Test*. When an assert fails pytest shows you exactly what the actual and expected values were — no need for assertEqual(). Fixtures (@pytest.fixture) provide setup/teardown and dependency injection for tests — database connections temporary files mock objects. Parametrize (@pytest.mark.parametrize) runs the same test with multiple input/output combinations eliminating test duplication. Mocking with unittest.mock.patch replaces real dependencies with controlled fakes making tests fast and isolated. Good unit tests: test one behavior run in milliseconds do not hit databases/networks/file systems (mock these) are deterministic (same result every run) and fail with clear messages.

Use generators file iteration (files are iterators in Python) or chunk-based reading. Never use read() or readlines() on large files — they load the entire file into memory.

Python file objects are iterators — you can iterate over them line by line without loading the entire file. For binary files or files where line iteration is not appropriate use file.read(chunk_size) to read fixed-size chunks in a loop. For CSV files use csv.DictReader (which iterates lazily) or pandas with chunksize parameter (pd.read_csv('file.csv' chunksize=10000) returns an iterator of DataFrames). For JSON use ijson for streaming JSON parsing. The with statement ensures the file is properly closed. For very large files (100GB+) memory-mapped files (mmap module) allow treating file content as if it were in memory while the OS handles paging.

Context length is the maximum number of tokens an LLM can process in a single call (input + output combined). It determines how much text you can send and receive. Exceeding it causes errors or truncation and longer contexts increase cost and latency.

Tokens are the fundamental units LLMs process — roughly 3-4 characters or 0.75 words per token in English. Context length limits how much text fits in one API call: GPT-4's 128k context allows roughly 96000 words while smaller models might allow only 4096 tokens. The entire prompt (system prompt + conversation history + retrieved documents + user message) plus the response must fit within this limit. Context length matters for: conversation history management (older messages must be truncated or summarized) RAG systems (limiting how many retrieved chunks can be included) document processing (whether you process entire documents or must chunk them) and cost (most APIs charge per token — 128k context calls cost much more than 4k calls even for short responses).

Temperature controls the randomness of token selection by scaling the probability distribution. Top_p (nucleus sampling) limits selection to the smallest set of tokens whose cumulative probability exceeds p. Both control output diversity but differently.

Language models output a probability distribution over the vocabulary for the next token. Temperature scales this distribution before sampling. Temperature=1 is the raw distribution. Temperature1 flattens it (more random more creative more likely to produce unusual tokens). Temperature=0 is greedy — always picks the highest probability token. Top_p=0.9 means: sort tokens by probability keep the top tokens until their cumulative probability reaches 90% sample only from those. This dynamically adjusts the candidate set size based on the distribution shape. Use temperature for general creativity control. Use top_p for better diversity control when the distribution is very peaked. Most APIs recommend using one or the other not both simultaneously.

A decorator is a function that wraps another function to add behavior. Without functools.wraps the wrapper loses the original function's metadata like __name__ and __doc__.

Decorators work by taking a function as input and returning a new function that adds behavior before or after the original call. The syntax @decorator is syntactic sugar for function = decorator(function). The core problem is that the returned wrapper function has its own identity — its __name__ is 'wrapper' not the original function's name. This breaks logging debugging and documentation tools. functools.wraps(original_func) applied to the wrapper copies the original function's metadata to the wrapper. This is especially critical in Flask and FastAPI where the routing system uses function names to identify view functions — without wraps all decorated routes have the same name and only one will be registered.

Chain-of-thought (CoT) prompting asks the LLM to show its reasoning step by step before giving a final answer. It significantly improves performance on multi-step reasoning tasks: math logic code debugging and complex analysis. It does not help (and can hurt) simple classification or recall tasks.

Standard prompting asks for the answer directly. CoT prompting adds 'Let's think step by step' or provides examples where the reasoning is shown before the answer. The improvement comes from the model using its output tokens to work through intermediate reasoning steps — effectively using the context window as a scratchpad. Zero-shot CoT adds 'think step by step'. Few-shot CoT provides worked examples. Auto-CoT automatically generates reasoning chains. CoT helps when: the task requires multiple steps errors in early steps compound (math logic) or when the model needs to 'check its work'. CoT does NOT help for: simple fact retrieval single-step tasks or tasks where the reasoning process cannot be decomposed into steps.

Context managers use __enter__ and __exit__ methods to manage setup and teardown of resources. The 'with' statement calls these automatically ensuring cleanup even if an exception occurs.

When you use 'with open(file) as f' Python calls f.__enter__() to set up and f.__exit__() to clean up. You can create custom context managers two ways: implement __enter__ and __exit__ in a class or use the @contextmanager decorator from contextlib with a generator function that yields once. The __exit__ method receives exception information and can suppress exceptions by returning True. Context managers are the Pythonic way to handle any resource that needs guaranteed cleanup: database connections locks temporary directories timers and transaction management.

Python dictionaries are hash tables. Lookup insertion and deletion are O(1) average case. Hash collisions can degrade this to O(n) worst case but Python's implementation makes this extremely rare. Python 3.7+ guarantees insertion-order preservation.

Dictionaries store key-value pairs in a hash table. When you set d[key] = value Python computes hash(key) maps it to a bucket and stores the value. When you access d[key] Python recomputes the hash and looks up the bucket directly — O(1). Hash collisions (two different keys mapping to the same bucket) are resolved via open addressing in CPython. Python 3.6 introduced a compact dictionary representation that stores insertion order as a side effect. Python 3.7 made insertion order preservation official. Only hashable objects can be dictionary keys (immutable types: strings integers tuples — but not lists or other dicts). dict.get(key default) avoids KeyError for missing keys. collections.defaultdict automatically creates default values. collections.Counter counts hashable objects.

Precision is the fraction of positive predictions that are actually positive. Recall is the fraction of actual positives that were correctly identified. F1 is their harmonic mean. Which matters depends on the cost of each type of error.

Precision = TP / (TP + FP). High precision means when you predict positive you are usually right (few false alarms). Recall = TP / (TP + FN). High recall means you catch most actual positives (few misses). There is a precision-recall tradeoff — increasing the classification threshold raises precision but lowers recall. F1 score = 2 * (precision * recall) / (precision + recall) balances both. Choose based on business cost: in spam detection low precision (legitimate emails marked spam) is worse than low recall (some spam gets through) — optimize precision. In cancer screening low recall (missing cancers) is catastrophic — optimize recall. In fraud detection both matter differently depending on churn cost vs fraud loss.

A Random Forest builds many decision trees on random subsets of data and features then aggregates their predictions. It is better than a single tree because averaging many uncorrelated trees reduces variance without increasing bias.

A single decision tree is prone to overfitting — it can grow arbitrarily complex and memorize training data. Random Forest addresses this with two randomness sources: bagging (each tree trains on a bootstrap sample — random sample with replacement of the training data) and feature randomness (at each split only a random subset of features is considered). These two mechanisms ensure the trees are decorrelated. Aggregating many decorrelated slightly overfit trees through voting (classification) or averaging (regression) dramatically reduces variance. Random Forests also provide feature importance scores by measuring how much each feature reduces impurity across all trees.