DEV Community: Ramesh S

Building a Policy Q&A System: Architecture, RAG, and Practical Lessons

Ramesh S — Tue, 15 Sep 2026 03:53:51 +0000

How I built a citizen-facing chatbot that answers policy questions with real citations - and what I learned trying to make it trustworthy, not just fluent.

The problem: policy documents are technically public, practically unreadable

Public services publish huge amounts of policy information - benefit rates, application requirements, eligibility rules. All of it is technically available online. Almost none of it is easy to actually use if you're not a specialist. A person just wants to know "how much am I entitled to" or "what documents do I need," and instead they get a 30-page policy document written for caseworkers, not citizens.

The result is predictable: people call a support line to ask something the answer to which is already published somewhere, or they give up and guess. Having worked on large, document-heavy digital services, I saw this gap constantly - not a lack of information, but a lack of a way to actually ask it a question.

So I built policy-qa-system - an open-source RAG (Retrieval-Augmented Generation) chatbot that lets people ask everyday questions about public policy in plain language, and get an answer that's grounded in an actual source document, with a citation attached. Not a general-purpose chatbot guessing at policy - a system that only answers from documents it's actually been given.

The solution: retrieve, read, answer, cite

When someone asks a question, the system:

Searches a store of indexed policy documents for the most relevant sections
Reads those sections alongside the question
Generates an answer in plain language, not policy jargon
Cites the exact source, so the answer can be checked, not just trusted

That last step is the one most chatbot projects skip, and it's the one that matters most here. An answer about benefit entitlement or application requirements is only useful if someone can verify it. So every response comes with a source reference, and the system is built to say "I'm not sure" rather than guess when nothing relevant is found.

A plain-language example

Question: "How much is the weekly payment for two children?"

Answer:

For 2 children: first child gets the standard rate, second child
gets the additional-child rate (combined weekly and yearly totals
shown together). An income-based charge may apply above a set
household income threshold.

Source: Official rates document, section on child payments

The exact numbers depend on which country's policy documents are loaded - the system itself is not tied to any one country's rules. It's a pattern for citizen Q&A, not a fixed dataset.

Tech stack

Layer	Technology
Frontend	React 18 + TypeScript + Tailwind CSS
Backend	Node.js + Express
AI / RAG	LangChain + LangGraph
Vector store	PostgreSQL + pgvector
Deployment	Docker

Nothing exotic here either. A team running this for real would replace the sample document set with their own official policy documents, and everything else - retrieval, citation, plain-language generation - stays the same.

Architecture

 User question
      │
      ▼
 React UI ──► Express API
      │
      ▼
 LangChain retrieval ──► PostgreSQL + pgvector (indexed policy docs)
      │
      ▼
 LLM answer generation (grounded in retrieved sections)
      │
      ▼
 Answer + citation + confidence score

The confidence score matters as much as the answer. If the retrieval step doesn't find anything close enough to the question, the system is designed to say so, rather than let the LLM fill the gap with a plausible-sounding guess.

Code walkthrough (the useful bits)

Every answer is required to carry a source, not just generated freely:

const response = await chain.invoke({
  question,
  context: retrievedChunks,
});

return {
  answer: response.answer,
  sources: retrievedChunks.map(c => ({
    document: c.metadata.document,
    section: c.metadata.section,
  })),
  confidence: response.confidence,
};

A confidence threshold decides whether to answer or say "not found":

if (topMatchScore < CONFIDENCE_THRESHOLD) {
  return {
    answer: "I couldn't find a reliable answer to that in the indexed documents.",
    sources: [],
  };
}

This one check is small in terms of code, but it's the difference between a chatbot people can trust and one that just sounds confident.

Lessons learned

What went well:

Making citations a required part of every answer, not an optional extra, forced better retrieval quality from the start - a vague retrieval result becomes obvious as soon as you have to show where it came from.
The confidence threshold, even a simple version of it, cut down on confident-sounding wrong answers a lot. It felt like a small addition but had one of the biggest effects on trust.
Keeping the document set swappable meant the same system could, in theory, work for very different policy areas just by re-indexing a different set of documents.

What was genuinely hard:

Plain-language translation without losing accuracy. Policy documents are precise for a reason - simplifying the wording without dropping an important condition (an income threshold, an eligibility rule) took real care, and I don't think it's fully solved yet.
Deciding when to say "I don't know." Set the confidence threshold too low, and the system answers questions it shouldn't. Set it too high, and it refuses questions it could actually answer well. I ended up tuning this by hand against a small test set of real questions.
This is a starting point, not a finished, ready-to-deploy system. It needs a real document ingestion pipeline, ongoing review of the sample answers, and proper testing against edge cases before anyone should point real users at it. I'd treat it as a solid base to build on, not a drop-in, ready-to-launch tool.

Where this fits into a bigger picture

This is one of a small set of open-source AI projects I'm building - a document Q&A RAG system, an AI code review agent, a voice-to-Agile-user-story tool. The common thread is using LLM orchestration (LangChain/LangGraph) on real workflow problems, with a strong bias toward answers that can be checked rather than answers that just sound right.

Try it / contribute

The repo is open source and quick to try locally:

git clone https://github.com/Srameshgitnow/policy-qa-system.git
cd policy-qa-system
npm install
npm run dev

Full setup steps, environment variables, and how to load your own documents are in the README.

If you try it, find a gap in the citation logic, or have ideas on the confidence threshold, I'd like to hear about it - issues and pull requests are open. And if the project is useful to you, a ⭐ on the repo helps other people find it:

👉 github.com/Srameshgitnow/policy-qa-system

I'm a full-stack / AI engineer (React, Node.js, LangChain/LangGraph) with a background in large-scale digital delivery. I write about applied AI engineering and open-source tools - follow along for the next post in this series.

Building an AI Code Review Agent: Architecture, LangGraph, and Practical Lessons

Ramesh S — Tue, 15 Sep 2026 03:30:45 +0000

How I built a multi-step AI agent that reviews pull requests automatically - and what I learned making it actually useful, not just clever.

The problem: code review doesn't scale with team size

Every team I've worked with hits the same wall. Pull requests pile up. Senior engineers are the only ones who catch the subtle bugs - the N+1 query, the hardcoded secret, the missing edge case - but senior engineers are also the busiest people on the team. So reviews get rushed, or they get delayed, and either way something slips through.

Most "AI code review" tools I looked at were closed-source, expensive, or both. I wanted to understand how one of these actually works under the hood, and build something a small team could run themselves, on their own repos, without sending code to a black box.

So I built agentic-code-reviewer - an open-source bot that listens for new pull requests on GitHub and reviews them using a multi-step AI agent built with LangGraph, then posts specific, line-level feedback as a PR comment.

The solution: webhook in, structured review out

When a pull request opens, the bot does this:

Receives the event through a GitHub webhook
Fetches the diff using the GitHub API (Octokit)
Runs it through a LangGraph agent that checks for security issues, performance problems, and architecture concerns, step by step
Posts a comment on the PR with specific, line-referenced feedback
Stores the review in a database, so review history builds up over time

The important part here is "step by step." A single prompt asking an LLM to "review this code" tends to give vague, generic feedback. Splitting the review into stages - security pass, performance pass, architecture pass - gives much more focused results, because each stage only has one job.

Tech stack

Layer	Technology
Agent framework	LangGraph (multi-step reasoning)
LLM	OpenAI GPT-4 or Claude (you choose)
Backend	Node.js + Express
Database	PostgreSQL (review history)
GitHub integration	Octokit
Webhooks	Express middleware + signature check

I kept the stack close to what most Node.js teams already run. The idea was never to show off a new framework - it was to build something a team could actually host and trust.

Architecture

 GitHub PR opened
        │
        ▼
 Webhook (signed, verified)
        │
        ▼
 Express API ──► Fetch diff (Octokit)
        │
        ▼
 LangGraph Agent
   ├── Security check
   ├── Performance check
   └── Architecture check
        │
        ▼
 Post PR comment + save to PostgreSQL

Each check in the LangGraph flow is its own node. This means I can test, tune, or even disable one check without touching the others - useful when a team only cares about security issues, for example, and doesn't want architecture opinions on every PR.

Code walkthrough (the useful bits)

Webhook signature checking, so random requests can't trigger a fake review:

function verifySignature(payload: string, signature: string) {
  const hmac = crypto.createHmac("sha256", process.env.GITHUB_WEBHOOK_SECRET!);
  const digest = "sha256=" + hmac.update(payload).digest("hex");
  return crypto.timingSafeEqual(Buffer.from(digest), Buffer.from(signature));
}

This is a small piece of code, but skipping it is a common mistake in webhook-based tools. Without it, anyone who finds your webhook URL could send fake events.

The LangGraph flow is built as separate nodes, not one big prompt:

const graph = new StateGraph(ReviewState)
  .addNode("security", securityCheckNode)
  .addNode("performance", performanceCheckNode)
  .addNode("architecture", architectureCheckNode)
  .addEdge("security", "performance")
  .addEdge("performance", "architecture");

Each node gets the diff and returns only its own findings, which then get combined into one comment. This made debugging much easier - if the performance check gave a strange answer, I only had to look at one node, not one giant prompt.

Lessons learned

What went well:

Splitting the review into separate checks (security, performance, architecture) gave noticeably better, more specific feedback than one combined prompt. This was the single biggest quality improvement in the whole project.
Verifying webhook signatures from day one meant I never had to go back and bolt on security later - it was part of the design from the start.
Storing review history in PostgreSQL, even in a simple form, made it easy to see patterns later - which kinds of issues came up most often across PRs.

What was genuinely hard:

False positives are part of the deal. LLM-based review sometimes flags things that aren't really problems. I had to be upfront about this in the docs rather than pretend the tool is always right - trust matters more than a perfect-sounding feature list.
Cost per review adds up. Running three separate LLM calls per PR (security, performance, architecture) is more accurate than one call, but it costs more and takes longer. I had to find a balance between review quality and cost that a small team could actually afford.
Getting comments to look like a human wrote them - short, specific, pointing at a line number - took more prompt iteration than the actual LangGraph logic did. Nobody reads a five-paragraph AI essay in a PR comment.

Where this fits into a bigger picture

This sits alongside a small set of open-source AI projects I'm building - a document Q&A RAG system, a policy Q&A tool for citizen-facing services, a voice-to-Agile-user-story generator. The thread running through all of them is the same: taking LLM orchestration (LangChain/LangGraph) and applying it to a real, specific workflow problem, instead of building a generic demo. This project is not a finished, ready-to-deploy product yet - it's a working, open-source starting point that a team could build on and harden for their own setup.

Try it / contribute

The repo is open source and quick to try locally:

git clone https://github.com/Srameshgitnow/agentic-code-reviewer.git
cd agentic-code-reviewer
npm install
npm run dev

Full setup steps, environment variables, and how to wire up the GitHub webhook are in the README.

If you try it, hit a false positive, or have ideas on the LangGraph flow, I'd like to hear about it - issues and pull requests are open. And if the project is useful to you, a ⭐ on the repo helps other people find it:

👉 github.com/Srameshgitnow/agentic-code-reviewer

Building an AI Document Intelligence System: Architecture, LangChain, and Practical Lessons

Ramesh S — Mon, 14 Sep 2026 16:29:01 +0000

How I built a RAG system for document Q&A - and what years of working on document-heavy digital services taught me.

The problem: documents don't answer their own questions

Every organisation I've worked with has the same problem. Information sits inside PDFs, Word files, and scanned reports that nobody has time to read fully. A caseworker needs one line from a 40-page policy document. An analyst needs one number from page 22 of a report. The document is "available," but nobody can actually find anything in it quickly.

I've spent several years working on large, document-heavy digital services. I saw this problem again and again, in different teams and different industries. Teams either pay for a closed-source document AI tool with unclear pricing and unclear data rules, or they just keep searching by hand.

So I built AI-DocumentIntelligence - an open-source, self-hosted RAG (Retrieval-Augmented Generation) system for uploading documents and asking questions about them in plain language. I didn't want to build just another wrapper around an API. I wanted to build something simple enough that any team handling sensitive documents could trust it: open, swappable, and easy to check.

The solution: upload, chunk, embed, ask

At its core, the app does four things:

Takes in PDF, DOCX, or TXT documents
Splits them into small, meaningful chunks
Turns those chunks into embeddings and stores them in PostgreSQL using pgvector
Answers questions about the document in plain language, using either OpenAI or Anthropic Claude - you can switch between them with one setting

That last point matters more than it sounds. Most tutorial-style RAG projects lock you into one LLM provider. In real projects, that's a problem - you often need to switch providers for cost, rules, or availability, without rewriting the app. So LLM_PROVIDER is just a setting in this project, not something buried deep in the code.

Tech stack

Layer	Technology
Frontend	React 18 + TypeScript
Backend	Node.js + Express + TypeScript
AI / orchestration	LangChain
Vector store	PostgreSQL + pgvector
LLMs	OpenAI or Anthropic Claude (you choose)
Dev tooling	Docker, ts-node, dotenv

I kept the stack simple on purpose. Nothing here needs a team to learn a whole new way of deploying software. If you can already run a Node.js service and a PostgreSQL database, you can run this.

Architecture

 ┌────────────┐      ┌──────────────────┐      ┌────────────────────┐
 │  React UI   │ ───► │  Express API      │ ───► │  Document Processor │
 │ (upload+chat)│      │ (TypeScript)       │      │ (chunking / split)   │
 └────────────┘      └──────────────────┘      └────────────────────┘
                                │                          │
                                ▼                          ▼
                      ┌──────────────────┐      ┌────────────────────┐
                      │  LangChain Layer   │ ◄──► │ PostgreSQL + pgvector│
                      │ (OpenAI / Claude)    │      │  (embeddings store)   │
                      └──────────────────┘      └────────────────────┘

The chunking and embedding step runs once, when a document is uploaded. After that, each question follows a simple path: turn the question into an embedding, search pgvector for the closest chunks, send those chunks to the chosen LLM along with the question, and return the answer plus the chat history for that document.

Nothing fancy here. That's on purpose. The value isn't in a clever new architecture - it's in getting the simple parts right: choosing the right provider, splitting text well, and handling errors properly when a key or setting is missing.

Code walkthrough (the useful bits, not the whole repo)

Switching LLM providers is just reading a setting, not digging through the code:

// backend/src/llm/provider.ts (simplified)
const provider = process.env.LLM_PROVIDER; // "openai" | "anthropic"

export function getChatModel() {
  if (provider === "anthropic") {
    return new ChatAnthropic({
      apiKey: process.env.ANTHROPIC_API_KEY,
      model: process.env.ANTHROPIC_MODEL,
    });
  }
  return new ChatOpenAI({
    apiKey: process.env.OPENAI_API_KEY,
  });
}

Chunking uses LangChain's recursive splitter, tuned for Q&A rather than raw storage:

const splitter = new RecursiveCharacterTextSplitter({
  chunkSize: 1000,
  chunkOverlap: 150,
});
const chunks = await splitter.splitDocuments(rawDocs);

The overlap matters more than most tutorials say. Too little overlap, and an answer gets cut in half across two chunks. Too much overlap, and you pay to store and search the same sentence three times. 150 overlap on a 1000-character chunk worked best across the mixed PDF and DOCX files I tested.

Retrieval and generation are kept separate. This means I can test each part on its own. I can check that retrieval finds the right chunks without spending API credits on generation - which matters a lot when you're working on a free-tier OpenAI account.

Lessons learned

What went well:

Making the LLM provider swappable from day one paid off fast. I built and tested most of the retrieval logic using free, local embeddings before I ever touched a paid API. This kept my costs close to zero while building.
Keeping chunking/embedding separate from the question-answering step made debugging much easier. If something looked wrong, I could quickly tell whether it was a retrieval problem or a generation problem.
Using Docker Compose for the whole stack (backend + frontend + Postgres) meant anyone else could clone the repo and have it running in minutes, not an afternoon of dependency problems.

What was genuinely hard:

Building without paid API credits. Building a RAG system without a paid OpenAI or Claude account is a real limit, not a small detail. I ended up testing retrieval with free, local embedding models first, then adding the paid generation step later. I'd recommend this to anyone building RAG on a tight budget, in any field.
Getting chunk size right is unglamorous but very important. No amount of prompt tuning fixes a bad chunk split. I underestimated this at first, and fixing it gave the single biggest improvement in the whole project.
"Works on my laptop" and "works when someone else runs docker compose up" are two different things. Getting the second one right - a clear .env.example, clear database name settings, a documented fix for port conflicts - took longer than writing the actual RAG logic. But it's the part that decides whether anyone else can actually use the project.

Where this fits into a bigger picture

I'm building this alongside a small set of open-source AI projects - a policy Q&A RAG system for citizen-facing services, an AI code review agent, a voice-to-Agile-user-story tool. They all follow the same idea: using LLM orchestration (LangChain/LangGraph) to solve real workflow problems I've seen in large-scale digital delivery work, not just building demos. If my background in real-world delivery work plus this kind of open-source AI work is useful context for anyone looking at this project, that's a big part of why I'm writing this.

Try it / contribute

The repo is open source, and you can run it locally in a few commands:

git clone https://github.com/Srameshgitnow/AI-DocumentIntelligence.git
cd AI-DocumentIntelligence
docker compose up --build

Full setup steps, environment variables, and troubleshooting tips are in the README.

If you try it, find a bug, or have thoughts on the provider-switching approach, I'd like to hear about it - issues and pull requests are open. And if you find the project useful, a ⭐ on the repo really helps other people find it:

👉 github.com/Srameshgitnow/AI-DocumentIntelligence

LangChain for Absolute Beginners - Part 6: Debugging & Observing Agents with LangSmith

Ramesh S — Thu, 30 Jul 2026 13:14:13 +0000

Over this series you've built an agent that reasons (Part 3), reads your documents (Part 4), and remembers conversations while respecting guardrails (Part 5). There's one problem: right now, if it picks the wrong tool or gives a strange answer, you're debugging blind - printing messages by hand and guessing.

LangSmith is LangChain's observability platform. It records every step of every agent run - every model call, every tool call, every token - as a structured, inspectable trace. This final article in the series shows you how to turn it on and actually use it.

Recap: The Series So Far

Part 1 - What LangChain is & your first script
Part 2 - Prompts, models, and LCEL chains
Part 3 - Tools and your first agent
Part 4 - RAG: reading your own documents
Part 5 - Memory and middleware
Part 6 (this article) - Debugging and observing with LangSmith

Why You Need This

Agents are non-deterministic and multi-step by nature - the same question can trigger a different sequence of tool calls on different runs. Print statements don't scale to that. LangSmith gives you a visual, timestamped tree of exactly what happened on any given run: which tool was called, with what arguments, what it returned, how many tokens were used, and how long each step took.

Step 1: Get a LangSmith API Key

Step 2: Turn On Tracing

Add these to your .env file:

LANGSMITH_TRACING=true
LANGSMITH_API_KEY=your-langsmith-key-here
LANGSMITH_PROJECT=langchain-beginner-series

LANGSMITH_PROJECT is optional - traces group under "default" if you skip it - but naming your project keeps traces organized once you have more than one app running.

Step 3: Run Any Agent From This Series - No Code Changes Needed

This is the best part: tracing is automatic. Take the RAG agent from Part 4 and just run it again with those environment variables set:

from dotenv import load_dotenv
from langchain.agents import create_agent

load_dotenv()

agent = create_agent(
    "gpt-5",
    tools=[search_company_docs],
    system_prompt="You are a helpful support assistant. Use the search tool when relevant.",
)

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is our refund policy?"}]}
)
print(response["messages"][-1].content)

Nothing in this code mentions LangSmith. As long as the environment variables are set, LangChain's tracer picks up every step automatically and ships it to your LangSmith project - that's the whole integration.

Step 4: Reading a Trace

Open your project on smith.langchain.com and click into the run. You'll see a nested tree that mirrors the agent loop from Part 3:

The top-level AgentExecutor (or graph) run, with total latency and token count
A ChatModel run showing the exact prompt sent, including your system prompt and every prior message
A Tool run for each tool call, showing the exact arguments the model chose and what your function returned
The final ChatModel run that produced the answer you saw in your terminal

This is where the "black box" feeling of agents disappears. If your Part 4 RAG agent gives a wrong answer, you can open the trace, look at exactly which chunks the retriever tool returned, and immediately see whether the problem was bad retrieval or the model misreading good context - the same diagnosis we did by hand with print() statements back in Part 4, except now it's a click away for every run, not just the one you happened to be debugging.

Step 5: Tagging and Filtering Runs

Once your app is used by more than just you, add metadata to your calls so you can filter traces later - by user, by feature, or by conversation:

config = {
    "configurable": {"thread_id": "conversation-1"},
    "tags": ["support-agent", "production"],
    "metadata": {"user_id": "user-42"},
}

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is our refund policy?"}]},
    config=config,
)

Now, in LangSmith, you can filter to just this user's traces, or just this feature's traces, instead of scrolling through everything.

A Quick Word on Evaluation

Tracing tells you what happened on a run you already made. LangSmith also supports evaluations - running a fixed set of test questions against your agent automatically and scoring the answers, so you catch regressions before you ship a prompt or tool change. That's a deeper topic on its own; for now, tracing alone will solve the vast majority of the debugging pain you've likely already felt while working through this series.

Series Wrap-Up

Here's everything you've built, in order:

Part 1: A basic chat model call and your first tool-using agent
Part 2: Reusable prompts and multi-step LCEL chains
Part 3: A real agent that reasons about which tool to call
Part 4: RAG - grounding answers in your own documents
Part 5: Memory across turns, plus middleware for guardrails and human approval
Part 6: Full visibility into what your agent actually did, with LangSmith

That's the complete path from "never touched LangChain" to a genuinely production-shaped agent - reasoning, grounded, persistent, guarded, and observable. From here, the best next step is picking a real project of your own and rebuilding it with everything from this series, one piece at a time.

Thanks for following along - if you build something with this series, I'd love to hear about it in the comments.

This is Part 6, the final article, of a 6-part LangChain beginner series.

LangChain for Absolute Beginners - Part 5: Memory & Middleware

Ramesh S — Thu, 30 Jul 2026 13:07:33 +0000

Every agent we've built so far forgets everything the moment invoke() returns. Ask it a follow-up question and it has no idea what you were just talking about. In this article we fix that with memory, and then add middleware - LangChain's mechanism for enforcing rules around what an agent is allowed to do.

Recap: The Series So Far

Part 1 - What LangChain is & your first script
Part 2 - Prompts, models, and LCEL chains
Part 3 - Tools and your first agent
Part 4 - RAG: reading your own documents
Part 5 (this article) - Memory and middleware
Part 6 - Debugging and observing agents with LangSmith

Why Agents Forget by Default

Each call to agent.invoke(...) runs the agent loop from a blank slate - there's no built-in place for previous messages to live between calls. To fix that, LangChain agents support a checkpointer: a component that saves the conversation's state after every step, keyed by a thread_id you choose.

Step 1: Add a Checkpointer

from dotenv import load_dotenv
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

load_dotenv()

checkpointer = InMemorySaver()

agent = create_agent(
    "gpt-5",
    checkpointer=checkpointer,
    system_prompt="You are a helpful, concise assistant.",
)

config = {"configurable": {"thread_id": "conversation-1"}}

agent.invoke(
    {"messages": [{"role": "user", "content": "Hi! My name is Ramesh."}]},
    config=config,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What's my name?"}]},
    config=config,
)

print(result["messages"][-1].content)

The second call correctly answers "Ramesh" - even though it's a separate invoke() call - because both calls share the same thread_id. Change the thread_id and you get a completely fresh conversation, which is exactly how you'd isolate memory per user or per chat session in a real app.

InMemorySaver keeps everything in your process's memory, so it disappears when your script exits. For anything you want to survive a restart, swap it for PostgresSaver or another persistent checkpointer - same pattern we've used throughout this series: change one line, keep the rest of your code.

Step 2: Keep Conversations From Growing Forever

Long conversations eventually blow past a model's context window, and cost money on every turn besides. LangChain's @before_model hook lets you trim the message list right before it's sent to the model:

from typing import Any
from langchain.messages import RemoveMessage
from langgraph.graph.message import REMOVE_ALL_MESSAGES
from langchain.agents import AgentState
from langchain.agents.middleware import before_model
from langgraph.runtime import Runtime

@before_model
def trim_messages(state: AgentState, runtime: Runtime) -> dict[str, Any] | None:
    """Keep only the most recent messages to stay within context limits."""
    messages = state["messages"]
    if len(messages) <= 6:
        return None  # nothing to trim yet

    first_msg = messages[0]
    recent_messages = messages[-5:]
    return {
        "messages": [RemoveMessage(id=REMOVE_ALL_MESSAGES), first_msg, *recent_messages]
    }

agent = create_agent(
    "gpt-5",
    checkpointer=checkpointer,
    middleware=[trim_messages],
)

This is middleware: a function that intercepts the agent loop at a defined point - here, right before every model call - and gets a chance to modify what happens next.

Step 3: Require Human Approval for Sensitive Tools

The most important middleware pattern for production agents is human-in-the-loop. If a tool can send an email, charge a card, or delete data, you generally don't want the model taking that action unsupervised.

from langchain.agents.middleware import HumanInTheLoopMiddleware

agent = create_agent(
    "gpt-5",
    tools=[send_email, get_weather],
    middleware=[
        HumanInTheLoopMiddleware(
            interrupt_on={
                "send_email": {"allowed_decisions": ["approve", "reject"]},
            }
        )
    ],
    checkpointer=checkpointer,
)

With this in place, whenever the agent decides to call send_email, execution pauses and hands control back to your application instead of firing the tool immediately. Your app can then show the proposed email to a human, and only actually send it once approved - the agent literally cannot bypass this gate, because it's enforced outside the model's control, not requested of it.

Notice get_weather isn't listed in interrupt_on - only tools you name there get the approval gate, so low-risk tools keep running automatically.

Putting It Together

A production-grade support agent might combine everything from this series so far:

agent = create_agent(
    "gpt-5",
    tools=[search_company_docs, send_email],          # Part 3 & 4
    system_prompt="You are a support assistant...",    # Part 2
    checkpointer=checkpointer,                          # memory, this part
    middleware=[trim_messages, HumanInTheLoopMiddleware(
        interrupt_on={"send_email": {"allowed_decisions": ["approve", "reject"]}}
    )],                                                  # guardrails, this part
)

That's a genuinely production-shaped agent in about ten lines - remembers the conversation, grounds answers in your documents, and can't send an email without a human saying yes.

What's Next

In the final article of this series, Part 6, we have covered how to actually see what your agent is doing - tracing every model call and tool call with LangSmith, and using that visibility to debug the inevitable cases where an agent picks the wrong tool or gets stuck in a loop.

This is Part 5 of a 6-part LangChain beginner series.

LangChain for Absolute Beginners - Part 4: RAG - Teaching Your Agent to Read Documents=

Ramesh S — Thu, 30 Jul 2026 12:58:19 +0000

Every model has a knowledge cutoff, and none of them have ever seen your company's internal wiki, your PDFs, or last week's meeting notes. Retrieval-Augmented Generation (RAG) solves this by fetching relevant chunks of your documents at question time and feeding them into the model's context before it answers.

By the end of this article, your agent from Part 3 will be able to answer questions about a document it was never trained on.

Recap: The Series So Far

Part 1 - What LangChain is & your first script
Part 2 - Prompts, models, and LCEL chains
Part 3 - Tools and your first agent
Part 4 (this article) - RAG: reading your own documents
Part 5 - Memory and middleware
Part 6 - Debugging and observing agents with LangSmith

The RAG Pipeline, Conceptually

RAG has two phases:

Indexing (done once, offline): Load your documents → split them into small chunks → convert each chunk into a numeric vector ("embedding") → store those vectors in a vector store.
Retrieval (done on every question): Convert the user's question into a vector the same way → find the stored chunks whose vectors are most similar → hand those chunks to the model as extra context.

The model never "reads your whole document." It only ever sees the handful of chunks that were judged most relevant to the specific question - which is exactly why chunking and retrieval quality matter so much.

Step 1: Install What You Need

pip install langchain langchain-openai langchain-text-splitters langchain-community

Step 2: Load and Split a Document

Let's index a plain text file. (The same pattern works for PDFs, web pages, and more - only the loader class changes.)

from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter

loader = TextLoader("company_faq.txt")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
)
doc_splits = splitter.split_documents(docs)

print(f"Split into {len(doc_splits)} chunks")

Why split at all? Two reasons: embedding models work better on focused, shorter passages than on entire documents, and it keeps the context you eventually feed the model tight and relevant instead of bloated. chunk_overlap=50 keeps a little context from the end of one chunk carried into the next, so you don't awkwardly cut a sentence in half at a chunk boundary.

Step 3: Embed and Store

from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings

vectorstore = InMemoryVectorStore.from_documents(
    documents=doc_splits,
    embedding=OpenAIEmbeddings(),
)

retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

InMemoryVectorStore is perfect for learning and small projects - no separate database to run. For production apps with thousands of documents, you'd swap this one line for something like Chroma, Pinecone, or FAISS; the rest of your pipeline doesn't change, which is the same "swap the component, keep the interface" pattern we saw with chat models in Part 1.

search_kwargs={"k": 3} tells the retriever to return the 3 most relevant chunks per question - a starting point worth tuning for your own data.

Step 4: Turn Retrieval Into a Tool

This is the key idea that connects RAG back to what you learned in Part 3: retrieval is just another tool. Instead of hardcoding "always search the docs," we let the agent decide when a question actually needs your documents versus when it can answer directly.

from langchain.tools import tool

@tool
def search_company_docs(query: str) -> str:
    """Search the company FAQ document for information relevant to the query."""
    results = retriever.invoke(query)
    return "\n\n".join(doc.page_content for doc in results)

Step 5: Build the RAG Agent

from dotenv import load_dotenv
from langchain.agents import create_agent

load_dotenv()

agent = create_agent(
    "gpt-5",
    tools=[search_company_docs],
    system_prompt=(
        "You are a helpful support assistant. "
        "Use the search_company_docs tool to answer questions about company policy. "
        "If the docs don't contain the answer, say so honestly instead of guessing."
    ),
)

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is our refund policy?"}]}
)

print(response["messages"][-1].content)

Notice the instruction "if the docs don't contain the answer, say so honestly instead of guessing" in the system prompt. This is one of the most important lines you'll write in any RAG app - without it, models will often confidently invent a plausible-sounding answer instead of admitting the retrieved chunks didn't cover the question.

A Quick Sanity Check

Before trusting a RAG pipeline, always look at what got retrieved, not just the final answer:

results = retriever.invoke("What is our refund policy?")
for i, doc in enumerate(results, 1):
    print(f"--- Chunk {i} ---")
    print(doc.page_content[:200], "...\n")

If the printed chunks don't actually contain refund information, the problem is in your indexing (chunk size, overlap, or embedding choice) - not in the model. This is the single most common debugging step for RAG apps, and it's worth doing before you touch the prompt.

What's Next

Your agent can now reason (Part 3) and ground its answers in your own data (Part 4). In Part 5, we added memory, so it remembers earlier turns in a conversation, and middleware, so you can enforce rules like "always ask for confirmation before calling a sensitive tool."

This is Part 4 of a 6-part LangChain beginner series.

LangChain for Absolute Beginners - Part 3: Tools & Building Your First Real Agent

Ramesh S — Wed, 29 Jul 2026 17:34:34 +0000

In Part 2, we built chains - fixed pipelines where the steps are always the same: prompt, then model, then parser. Chains are predictable, but they can't do anything a human didn't explicitly script in advance.

Agents flip that around. Instead of a fixed path, you hand the model a set of tools and let it decide, at run time, which ones to call, in what order, and when it's done. That's what we're building today.

Recap: The Series So Far

Part 1 - What LangChain is & your first script
Part 2 - Prompts, models, and LCEL chains
Part 3 (this article) - Tools and your first agent
Part 4 - RAG: teaching your agent to read documents
Part 5 - Memory and middleware
Part 6 - Debugging and observing agents with LangSmith

What Is a Tool?

A tool is just a normal Python function, with two things added so the model can understand it:

A clear docstring explaining what it does and when to use it
Type hints on its parameters, so LangChain can build a schema the model understands

LangChain turns that function into something the model can "see" and choose to call, using the @tool decorator.

from langchain.tools import tool

@tool
def get_weather(city: str) -> str:
    """Get the current weather for a given city."""
    # In a real app, you'd call a weather API here
    fake_data = {"chennai": "32°C, humid", "london": "16°C, cloudy"}
    return fake_data.get(city.lower(), "No data for that city.")

That's it - get_weather is now a tool. Two things matter enormously here:

The docstring is not a comment - the model reads it to decide whether this tool is relevant to the user's question. A vague docstring means the model may never call your tool, or call it at the wrong time.
Type hints define the tool's schema. city: str tells LangChain (and the model) that this tool expects a single string argument named city.

Building Your First Agent

Now let's give an agent a small toolbox and watch it reason about which tool to use.

from dotenv import load_dotenv
from langchain.agents import create_agent
from langchain.tools import tool

load_dotenv()

@tool
def get_weather(city: str) -> str:
    """Get the current weather for a given city."""
    fake_data = {"chennai": "32°C, humid", "london": "16°C, cloudy"}
    return fake_data.get(city.lower(), "No data for that city.")

@tool
def add_numbers(a: float, b: float) -> float:
    """Add two numbers together and return the result."""
    return a + b

agent = create_agent(
    "gpt-5",
    tools=[get_weather, add_numbers],
    system_prompt="You are a helpful assistant. Use tools when they help answer the question.",
)

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather in Chennai, and what's 45 + 78?"}]}
)

print(response["messages"][-1].content)

Run this, and the agent will:

Read the question and notice it actually contains two sub-tasks
Call get_weather("Chennai")
Call add_numbers(45, 78)
Combine both tool results into one coherent final answer

You never wrote an if/else to decide "call the weather tool" vs "call the math tool" - the model figured that out from the docstrings and the user's question.

Peeking Inside the Agent's Reasoning

It's worth seeing the intermediate steps at least once, so the "loop" from Part 1 stops feeling like magic:

response = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather in London?"}]}
)

for msg in response["messages"]:
    print(f"{msg.__class__.__name__}: {msg.content}")

You'll see something like:

HumanMessage: the original question
AIMessage: the model deciding to call get_weather, with no content yet
ToolMessage: the string your function returned
AIMessage: the final, natural-language answer

This is the agent loop: model → tool call → tool result → back to the model → repeat until the model has enough information to answer without calling another tool.

Giving Tools Better Structure with Pydantic

For tools with several parameters, docstrings alone get messy. You can define an explicit input schema with Pydantic for more reliable parsing:

from pydantic import BaseModel, Field
from langchain.tools import tool

class SearchInput(BaseModel):
    query: str = Field(description="The search term to look up")
    max_results: int = Field(default=5, description="Maximum number of results to return")

@tool(args_schema=SearchInput)
def search_docs(query: str, max_results: int = 5) -> str:
    """Search internal documentation for a given query."""
    return f"Found {max_results} results for '{query}' (placeholder)."

This isn't necessary for simple tools, but it becomes valuable once your tools have optional parameters, defaults, or validation rules you want enforced before the function ever runs.

A Word on Safety

Agents that call tools autonomously are powerful - and that's exactly why you should think about what each tool is allowed to do before wiring it up. A tool that deletes files, sends emails, or hits a paid API should never be handed to an agent without limits. In Part 5, we'll cover middleware, LangChain's mechanism for adding guardrails like human approval steps and rate limits around tool calls.

What's Next

You've now built a real agent that reasons about which tool to use - the core skill behind everything from customer support bots to coding assistants. In Part 4, we connected an agent to your own documents using RAG (Retrieval-Augmented Generation), so it can answer questions grounded in content it was never trained on.

This is Part 3 of a 6-part LangChain beginner series. Catch up on Part 1 and Part 2 if you missed them.

LangChain for Absolute Beginners - Part 2: Prompts, Models & LCEL Chains

Ramesh S — Wed, 29 Jul 2026 17:29:37 +0000

In Part 1, we installed LangChain and sent our first message to a chat model. That's fine for a one-off question, but real applications need repeatable, reusable prompts - and the ability to connect several steps into a pipeline. That's what we're covering today: prompt templates and LCEL (LangChain Expression Language).

Recap: The Series So Far

Part 1 - What LangChain is & your first script
Part 2 (this article) - Prompts, models, and LCEL chains
Part 3 - Tools and building your first agent
Part 4 - RAG: teaching your agent to read documents
Part 5 - Memory and middleware
Part 6 - Debugging and observing agents with LangSmith

Why You Need Prompt Templates

Hardcoding a prompt as a plain string works until you need to reuse it with different inputs. Compare:

# Without a template - repetitive and error-prone
prompt1 = "Explain machine learning in 3 bullet points."
prompt2 = "Explain quantum computing in 3 bullet points."

# With a template - define the structure once, reuse it forever
from langchain_core.prompts import PromptTemplate

prompt = PromptTemplate.from_template(
    "Explain {topic} in 3 bullet points."
)

A PromptTemplate is just a string with {placeholders} that get filled in at run time. It looks trivial here, but it becomes essential once your prompts grow to include instructions, examples, and formatting rules that you don't want to retype every time.

Chat Prompts with Roles

Most modern LLMs work with role-based messages (system, human, ai), not a single flat string. LangChain's ChatPromptTemplate mirrors that:

from langchain_core.prompts import ChatPromptTemplate

chat_prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a friendly Python tutor who explains things simply."),
    ("human", "Explain {topic} in 3 bullet points."),
])

The system message sets the model's persona and ground rules once, and every user question inherits that behavior - this is how you give an app a consistent "voice."

Introducing LCEL: The Pipe Operator

Here's where LangChain starts to feel genuinely different from calling an API directly. LCEL lets you connect components with the | operator, the same way you'd pipe commands together in a Unix shell.

from dotenv import load_dotenv
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain.chat_models import init_chat_model

load_dotenv()

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a friendly Python tutor who explains things simply."),
    ("human", "Explain {topic} in 3 bullet points."),
])

model = init_chat_model("gpt-5", model_provider="openai")
parser = StrOutputParser()

chain = prompt | model | parser

result = chain.invoke({"topic": "list comprehensions"})
print(result)

Read the chain = prompt | model | parser line like a sentence: "Take the input, run it through the prompt template, send that to the model, then parse the model's reply into a plain string."

Each piece - prompt, model, parser - is a Runnable, LangChain's standard interface for "something that takes an input and produces an output." Because everything implements the same interface, you can swap any piece out (a different model, a different parser, an extra step) without rewriting the rest of the chain.

What Does the Output Parser Do?

Without StrOutputParser, chain.invoke(...) would return a full Message object (the same one you saw in Part 1) instead of plain text. The parser is a small, focused Runnable that unwraps .content for you, so result above is already a ready-to-use string.

Multi-Step Chains

The real payoff of LCEL is chaining more than two steps. Let's build a two-stage pipeline: first generate a story title, then use that title to write a one-line pitch.

title_prompt = ChatPromptTemplate.from_template(
    "Write a short, catchy title for a story about {topic}."
)
pitch_prompt = ChatPromptTemplate.from_template(
    "Write a one-sentence pitch for a story titled '{title}'."
)

title_chain = title_prompt | model | parser
pitch_chain = pitch_prompt | model | parser

topic = "a robot learning to paint"
title = title_chain.invoke({"topic": topic})
pitch = pitch_chain.invoke({"title": title})

print("Title:", title)
print("Pitch:", pitch)

Notice the output of title_chain feeds directly into the input of pitch_chain. As your pipelines grow, you can compose these with RunnablePassthrough and dictionary-shaped steps to pass multiple values through several stages at once - we'll use that pattern when we build a RAG pipeline in Part 4.

Streaming Output

One more Runnable superpower: every chain built with LCEL automatically supports streaming, batching, and async execution, without extra code.

for chunk in chain.stream({"topic": "recursion"}):
    print(chunk, end="", flush=True)

This is the same chain object from earlier - just call .stream() instead of .invoke() and you get tokens as they're generated, which is exactly how ChatGPT-style typing effects are built.

What's Next

You now know how to structure prompts and connect steps into a pipeline - the two ingredients every LangChain app is built from. In Part 3, we have given a model tools it can call on its own, and use create_agent to build a real decision-making agent, not just a fixed pipeline.

This is Part 2 of a 6-part LangChain beginner series. Catch up on Part 1 if you missed it, and follow along for the rest of the series.

LangChain for Absolute Beginners - Part 1: What Is LangChain & Your First AI-Powered Script

Ramesh S — Wed, 29 Jul 2026 17:15:11 +0000

If you've played with the OpenAI or Anthropic API and thought "this is cool, but wiring together prompts, tools, and memory by hand is getting messy" - that's exactly the problem LangChain was built to solve.

This is Part 1 of a beginner-friendly series that will take you from "never touched LangChain" to "built and understood a working AI agent." No prior AI framework experience needed - just basic Python.

What You'll Learn in This Series

Part 1 (this article) - What LangChain is, installing it, and your first script
Part 2 - Chat models, prompts, and chaining steps together
Part 3 - Tools and building your first real agent
Part 4 - Retrieval-Augmented Generation (RAG): letting your agent read your documents
Part 5 - Memory and middleware: agents that remember and follow rules
Part 6 - Debugging and observing agents with LangSmith

So, What Is LangChain?

LangChain is an open-source Python (and JavaScript) framework for building applications powered by large language models - chatbots, research assistants, document Q&A tools, and autonomous agents that can call external tools on their own.

Instead of manually stitching together an LLM API call, a prompt template, a tool the model can invoke, and the logic that loops until the model is "done," LangChain gives you pre-built building blocks for all of it. The centerpiece of the modern LangChain API is a function called create_agent, which assembles a model, a prompt, and a set of tools into a working agent in just a few lines.

Under the hood, LangChain agents actually run on LangGraph, LangChain's lower-level orchestration engine. You don't need to learn LangGraph to follow this series - think of it as the engine bolted underneath the car you're about to drive.

Why Not Just Call the API Directly?

You certainly can call openai or anthropic Python SDKs directly, and for a single prompt-in, text-out use case, that's often enough. LangChain starts paying off once you need:

The same code to work across different model providers (OpenAI, Anthropic, Google, etc.)
A model that can decide, on its own, to call a search tool, a calculator, or your company's internal API
Retrieval from your own documents (PDFs, wikis, databases) blended into the model's answers
Conversation memory that persists across turns
Guardrails - like limiting how many tool calls an agent can make, or redacting sensitive data

We'll build toward all of these over the series. Today, we just get the lights turned on.

Step 1: Set Up Your Environment

Create a project folder and a virtual environment, exactly like we did for the Python and TypeScript series:

mkdir langchain-beginner
cd langchain-beginner
python -m venv venv
source venv/bin/activate   # On Windows: venv\Scripts\activate

Step 2: Install LangChain

pip install langchain langchain-openai

langchain is the core framework. langchain-openai is the integration package for OpenAI models - swap it for langchain-anthropic or langchain-google-genai if you prefer a different provider. LangChain supports 1,000+ integrations, but you only install the ones you actually use.

Step 3: Add Your API Key

Create a .env file in your project folder:

OPENAI_API_KEY=your-key-here

Then install python-dotenv so Python can read it:

pip install python-dotenv

Never commit your .env file to GitHub. Add it to .gitignore immediately.

Step 4: Your First LangChain Script

Let's write the simplest possible LangChain program - send a message to a chat model and print the response.

from dotenv import load_dotenv
from langchain.chat_models import init_chat_model

load_dotenv()

model = init_chat_model("gpt-5", model_provider="openai")

response = model.invoke("Explain what LangChain is in one sentence, for a total beginner.")
print(response.content)

Run it:

python first_script.py

You should see a plain-English explanation printed to your terminal.

What Just Happened?

init_chat_model is LangChain's universal entry point for chat models. Change the model name and provider string, and the rest of your code doesn't change - that's the "swap models without rewriting your app" promise in action.
model.invoke(...) sends your message and blocks until the full response comes back.
The response isn't a plain string - it's a Message object. .content gives you the text; other attributes (which we'll use later) carry token usage, tool calls, and more.

Step 5: Your First Taste of an Agent

Let's go one step further and see the feature that makes LangChain worth learning: an agent that can decide to use a tool.

from dotenv import load_dotenv
from langchain.agents import create_agent

load_dotenv()

def get_word_length(word: str) -> int:
    """Return the number of letters in a word."""
    return len(word)

agent = create_agent(
    "gpt-5",
    tools=[get_word_length],
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "How many letters are in 'LangChain'?"}]}
)

print(result["messages"][-1].content)

Here, create_agent builds a small loop: the model reads your question, notices it has a get_word_length tool available, decides to call it, receives the answer, and then writes a final reply - all automatically. This loop (model → tool call → tool result → model again) repeats until the model is confident it has a final answer, and that entire cycle is what people mean when they say "AI agent."

You just built one, in about ten lines.

What's Next

In Part 2, we have covered prompt templates and how to chain multiple steps together using LangChain Expression Language (LCEL) - the glue that lets you go from "one model call" to "a real pipeline."

This is Part 1 of a 6-part LangChain beginner series.

Python for Beginners — Part 8: Object-Oriented Python

Ramesh S — Tue, 23 Jun 2026 04:02:18 +0000

Part 8 of an 8-part beginner-friendly series on learning Python from scratch.

Congratulations — you've made it to the final part!

Everything you've learned — variables, control flow, collections, functions, file I/O, error handling — can be organized into classes and objects. This is object-oriented programming (OOP), and it's how professional Python code is written.

OOP isn't required to write working programs, but it's essential for writing code that scales, is maintainable, and professional. This final article brings everything together.

Classes and Objects

A class is a blueprint for creating objects. An object is an instance of that class. Think of a class like a cookie cutter and objects like the cookies it produces.

Defining a class

class Person:
    pass

# Create an object (instance)
person = Person()
print(person)  # <__main__.Person object at 0x...>

class Person: defines a class. person = Person() creates an object from that class.

The `init` Method and `self`

The __init__ method runs automatically when you create an object. It's where you initialize the object's data.

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

person = Person("Ramesh", 25)
print(person.name)  # Ramesh
print(person.age)   # 25

self represents the object itself. When you write self.name = name, you're saying "this object's name attribute equals the name I was given."

Think of it this way:

name (parameter) is the input
self.name (attribute) is the object's stored data

Creating multiple objects

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

person1 = Person("Ramesh", 25)
person2 = Person("Priya", 23)

print(person1.name, person1.age)  # Ramesh 25
print(person2.name, person2.age)  # Priya 23

Each object is independent. person1.name is separate from person2.name.

Methods

A method is a function inside a class. Methods operate on the object's data:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def greet(self):
        return f"Hello, I'm {self.name}"

    def have_birthday(self):
        self.age += 1

person = Person("Ramesh", 25)
print(person.greet())       # Hello, I'm Ramesh
person.have_birthday()
print(person.age)           # 26

Call methods with dot notation: person.greet(). The self parameter is passed automatically — you don't type it.

Instance vs Class Variables

Instance variables are unique to each object. Class variables are shared by all objects of that class:

class Dog:
    species = "Canis familiaris"  # Class variable

    def __init__(self, name):
        self.name = name  # Instance variable

dog1 = Dog("Buddy")
dog2 = Dog("Max")

print(dog1.name)           # Buddy (unique to dog1)
print(dog2.name)           # Max (unique to dog2)
print(Dog.species)         # Canis familiaris (shared)
print(dog1.species)        # Canis familiaris (accessible via instance too)

Use class variables for data shared by all instances. Use instance variables for data unique to each instance.

Inheritance

Inheritance lets you create a new class based on an existing class. The new class inherits methods and attributes from the parent:

class Animal:
    def __init__(self, name):
        self.name = name

    def speak(self):
        return f"{self.name} makes a sound"

class Dog(Animal):
    def speak(self):
        return f"{self.name} barks"

class Cat(Animal):
    def speak(self):
        return f"{self.name} meows"

dog = Dog("Buddy")
cat = Cat("Whiskers")

print(dog.speak())  # Buddy barks
print(cat.speak())  # Whiskers meows

Dog and Cat inherit from Animal and override the speak() method. This is called method overriding.

Using `super()`

Call the parent class's method with super():

class Animal:
    def __init__(self, name):
        self.name = name

    def describe(self):
        return f"{self.name} is an animal"

class Dog(Animal):
    def __init__(self, name, breed):
        super().__init__(name)  # Call parent's __init__
        self.breed = breed

    def describe(self):
        parent_desc = super().describe()  # Call parent's describe
        return f"{parent_desc} and is a {self.breed}"

dog = Dog("Buddy", "Golden Retriever")
print(dog.describe())  # Buddy is an animal and is a Golden Retriever

super() lets you access the parent class without repeating code.

Polymorphism

Polymorphism means "many shapes" — the same function name works differently depending on the object type:

class Dog:
    def speak(self):
        return "Woof!"

class Cat:
    def speak(self):
        return "Meow!"

class Cow:
    def speak(self):
        return "Moo!"

animals = [Dog(), Cat(), Cow()]

for animal in animals:
    print(animal.speak())

# Output:
# Woof!
# Meow!
# Moo!

Each animal speaks differently, but you call the same method. This is polymorphism in action.

Encapsulation

Encapsulation is the idea of bundling data and methods together, and controlling access to them. Python uses naming conventions:

public_attribute — accessible from outside (convention)
_private_attribute — intended private (convention, not enforced)
__really_private — name-mangled, harder to access (enforced)

class BankAccount:
    def __init__(self, balance):
        self.__balance = balance  # "Private"

    def deposit(self, amount):
        if amount > 0:
            self.__balance += amount

    def withdraw(self, amount):
        if 0 < amount <= self.__balance:
            self.__balance -= amount

    def get_balance(self):
        return self.__balance

account = BankAccount(1000)
account.deposit(500)
print(account.get_balance())  # 1500

# Can't access directly:
# print(account.__balance)  # AttributeError (name-mangled)

The double underscore (__) makes the attribute private. Access it through methods instead. This prevents accidental misuse.

Dunder Methods

Dunder methods (double underscore) are special methods Python calls automatically. Here are the most important:

`str` and `repr`

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

    def __str__(self):
        return f"{self.name} ({self.age})"

    def __repr__(self):
        return f"Person('{self.name}', {self.age})"

person = Person("Ramesh", 25)
print(str(person))   # Ramesh (25) — human-readable
print(repr(person))  # Person('Ramesh', 25) — for debugging

__str__ is for end users. __repr__ is for developers.

`len`

class ShoppingCart:
    def __init__(self):
        self.items = []

    def add(self, item):
        self.items.append(item)

    def __len__(self):
        return len(self.items)

cart = ShoppingCart()
cart.add("apple")
cart.add("banana")
print(len(cart))  # 2

Now len(cart) returns the number of items.

`eq`

class Person:
    def __init__(self, name):
        self.name = name

    def __eq__(self, other):
        return self.name == other.name

person1 = Person("Ramesh")
person2 = Person("Ramesh")
print(person1 == person2)  # True (compares names)

Define how == works for your objects.

Properties and Getters/Setters

Properties let you access attributes like data, but with method-like control:

class Person:
    def __init__(self, name):
        self._name = name

    @property
    def name(self):
        return self._name

    @name.setter
    def name(self, value):
        if len(value) > 0:
            self._name = value

person = Person("Ramesh")
print(person.name)     # Ramesh (getter)
person.name = "Priya"  # Setter
print(person.name)     # Priya

The @property decorator makes name act like an attribute but run validation code.

Practical Examples

Example 1: User class

class User:
    def __init__(self, username, email):
        self.username = username
        self.email = email
        self.created_at = datetime.now()

    def __str__(self):
        return f"User({self.username})"

    def change_email(self, new_email):
        if "@" in new_email:
            self.email = new_email
        else:
            raise ValueError("Invalid email")

user = User("ramesh", "ramesh@example.com")
print(user)  # User(ramesh)
user.change_email("ramesh.new@example.com")

Example 2: Inheritance with Bank Accounts

class Account:
    def __init__(self, owner, balance):
        self.owner = owner
        self.balance = balance

    def deposit(self, amount):
        self.balance += amount

class SavingsAccount(Account):
    def __init__(self, owner, balance, interest_rate):
        super().__init__(owner, balance)
        self.interest_rate = interest_rate

    def apply_interest(self):
        self.balance *= (1 + self.interest_rate)

savings = SavingsAccount("Ramesh", 1000, 0.05)
savings.deposit(500)
savings.apply_interest()
print(savings.balance)  # 1575.0

Example 3: Polymorphism with shapes

class Shape:
    def area(self):
        raise NotImplementedError

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

    def area(self):
        return 3.14 * self.radius ** 2

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

shapes = [Circle(5), Rectangle(4, 6)]
for shape in shapes:
    print(f"Area: {shape.area()}")

# Output:
# Area: 78.5
# Area: 24

Why This Matters

OOP is how professional code is organized. Without it, programs become tangled messes of functions and variables. With OOP, you group related data and behavior together into classes, making code:

Reusable — inheritance lets you extend existing code
Maintainable — encapsulation hides complexity
Scalable — polymorphism lets you add new types easily
Clear — objects represent real-world concepts

The most common beginner mistakes:

Forgetting self in methods
Confusing __init__ (constructor) with class definition
Not using inheritance when it makes sense
Overcomplicating with too many classes (start simple)
Breaking encapsulation with direct attribute access

Your Journey is Complete

You've now learned:

Syntax and basics (Parts 1–2)
Working with text and logic (Parts 3–4)
Organizing data (Part 5)
Organizing code (Part 6)
Working in the real world (Part 7)
Professional code structure (Part 8: OOP)

You have all the fundamental skills of a Python programmer. Where you go from here is up to you — web development, data science, automation, games, machine learning — Python is everywhere.

What's Next

You've completed the 8-part beginner series. From here:

Web development: Flask or Django frameworks
Data science: Pandas, NumPy, Matplotlib
Automation: Scripts to automate tasks
Games: Pygame library
Machine learning: Scikit-learn, TensorFlow
Advanced Python: Decorators, metaclasses, async/await

The fundamentals you've learned here apply to everything. Pick a project that excites you and build it.

Python for Beginners — Part 7: Modules, Errors & Files

Ramesh S — Tue, 23 Jun 2026 03:54:20 +0000

Part 7 of a beginner-friendly series on learning Python from scratch.

In Part 6, we learned to write reusable functions. Now it's time to make those functions work in the real world: reading data from files, handling things when they go wrong, and using code other people have written.

This is where Python transitions from "learning exercises" to "actual programs." Real programs read files, talk to the internet, handle unexpected input, and use libraries to solve complex problems.

Modules and Imports

A module is a file containing Python code that you can reuse. Python comes with a huge standard library of modules, and you can also install external ones.

Using the math module

import math

print(math.sqrt(16))      # 4.0
print(math.pow(2, 3))     # 8.0
print(math.pi)            # 3.14159...
print(math.ceil(4.3))     # 5 (round up)
print(math.floor(4.7))    # 4 (round down)

import math loads the math module. You access its functions and constants with dot notation: math.sqrt(), math.pi, etc.

Importing specific items

If you only need a few things, import them directly:

from math import sqrt, pi

print(sqrt(16))   # 4.0 (no need for math.)
print(pi)         # 3.14159...

Now you use sqrt() directly, not math.sqrt().

Aliasing imports

Use as to give a module a shorter name:

import math as m

print(m.sqrt(16))  # 4.0

Or alias specific items:

from math import sqrt as square_root

print(square_root(16))  # 4.0

Working with datetime

The datetime module is essential for handling dates and times:

from datetime import datetime, timedelta

# Get current date and time
now = datetime.now()
print(now)  # 2024-06-23 14:30:45.123456

# Create a specific date
birthday = datetime(1999, 5, 15)
print(birthday)  # 1999-05-15 00:00:00

# Format as string
print(now.strftime("%Y-%m-%d"))  # 2024-06-23
print(now.strftime("%A, %B %d"))  # Sunday, June 23

# Time differences
future = now + timedelta(days=30)
print(future)  # Date 30 days from now

Working with JSON

JSON (JavaScript Object Notation) is a standard format for exchanging data. Python dictionaries map perfectly to JSON:

import json

# Convert Python dict to JSON string
person = {
    "name": "Ramesh",
    "age": 25,
    "city": "Chennai",
    "hobbies": ["reading", "coding", "gaming"]
}

json_string = json.dumps(person)
print(json_string)
# {"name": "Ramesh", "age": 25, "city": "Chennai", "hobbies": ["reading", "coding", "gaming"]}

# Convert JSON string back to Python dict
parsed = json.loads(json_string)
print(parsed["name"])  # Ramesh

Reading and writing JSON files:

import json

# Write to file
data = {"name": "Ramesh", "age": 25}
with open("data.json", "w") as file:
    json.dump(data, file)

# Read from file
with open("data.json", "r") as file:
    data = json.load(file)
    print(data)

Regular Expressions (Regex)

Regex is a language for pattern matching in text. It's powerful but takes time to master. Here are common patterns:

import re

text = "My phone is 555-1234 and email is user@example.com"

# Find a pattern
phone = re.search(r"\d{3}-\d{4}", text)
if phone:
    print(phone.group())  # 555-1234

# Find all matches
emails = re.findall(r"[\w.-]+@[\w.-]+\.\w+", text)
print(emails)  # ['user@example.com']

# Replace
cleaned = re.sub(r"\d", "X", text)
print(cleaned)  # Phone is XXX-XXXX...

# Check if pattern matches
if re.match(r"^\d+$", "12345"):
    print("It's all digits")

Regex patterns (a few common ones):

\d — any digit (0-9)
\w — any word character (letter, digit, underscore)
\s — any whitespace
. — any character
* — zero or more
+ — one or more
? — zero or one
{n} — exactly n times
^ — start of string
$ — end of string
[abc] — a, b, or c

Regex is complex; this is just an introduction. Most beginners use regex sparingly and look up patterns when needed.

File Input and Output

Reading files

# Simple read
with open("myfile.txt", "r") as file:
    content = file.read()
    print(content)

# Read line by line
with open("myfile.txt", "r") as file:
    for line in file:
        print(line.strip())  # strip() removes newline

# Read all lines as a list
with open("myfile.txt", "r") as file:
    lines = file.readlines()
    print(lines[0])  # First line

The with statement is crucial — it automatically closes the file when you're done, even if an error occurs.

Writing files

# Write (overwrites if file exists)
with open("output.txt", "w") as file:
    file.write("Hello, World!\n")
    file.write("Second line\n")

# Append (add to end of file)
with open("output.txt", "a") as file:
    file.write("Third line\n")

Working with file paths

import os

# Check if file exists
if os.path.exists("myfile.txt"):
    print("File found")

# Get file size
size = os.path.getsize("myfile.txt")
print(f"File size: {size} bytes")

# List files in directory
files = os.listdir(".")
print(files)

# Create directory
os.makedirs("my_folder", exist_ok=True)

# Delete file
os.remove("myfile.txt")

Exception Handling

Real programs fail sometimes — bad file paths, network errors, invalid input. Handle these gracefully with try/except:

try:
    # Code that might fail
    number = int("not a number")
except ValueError:
    print("That's not a valid number")

If int() fails, Python catches the ValueError and runs the except block instead of crashing.

Multiple exceptions

try:
    file = open("missing.txt", "r")
    number = int(file.read())
except FileNotFoundError:
    print("File doesn't exist")
except ValueError:
    print("File contains non-numeric data")
except Exception as e:
    print(f"Something went wrong: {e}")

Handle specific errors first, then generic ones. Exception catches everything.

Try, except, else, finally

try:
    file = open("data.txt", "r")
    data = file.read()
except FileNotFoundError:
    print("File not found")
else:
    # Runs if no exception occurred
    print(f"Successfully read {len(data)} characters")
finally:
    # Always runs, useful for cleanup
    print("Done")

try — code that might fail
except — what to do if it fails
else — what to do if it succeeds
finally — always runs (cleanup)

Raising exceptions

You can raise exceptions yourself:

def validate_age(age):
    if age < 0:
        raise ValueError("Age cannot be negative")
    if age > 150:
        raise ValueError("Age seems unrealistic")
    return True

try:
    validate_age(-5)
except ValueError as e:
    print(f"Invalid input: {e}")

Installing External Libraries with pip

The pip package manager lets you install libraries others have written:

pip install requests      # Install the requests library
pip install numpy pandas  # Install multiple packages
pip install requests==2.28.0  # Install specific version
pip list                  # Show installed packages
pip uninstall requests    # Remove a package

Once installed, use them like built-in modules:

import requests

response = requests.get("https://api.github.com")
print(response.status_code)  # 200

Popular libraries for beginners:

requests — make web requests
numpy — numerical computing
pandas — data analysis
matplotlib — plotting and visualization
flask — build web applications

Practical Examples

Example 1: Read and count words

def count_words(filename):
    try:
        with open(filename, "r") as file:
            content = file.read()
            words = content.split()
            return len(words)
    except FileNotFoundError:
        print(f"Error: {filename} not found")
        return 0

count = count_words("myfile.txt")
print(f"Total words: {count}")

Example 2: Save and load JSON data

import json

def save_contacts(contacts, filename):
    with open(filename, "w") as file:
        json.dump(contacts, file, indent=2)

def load_contacts(filename):
    try:
        with open(filename, "r") as file:
            return json.load(file)
    except FileNotFoundError:
        return []

# Save
contacts = [
    {"name": "Ramesh", "phone": "555-1234"},
    {"name": "Priya", "phone": "555-5678"}
]
save_contacts(contacts, "contacts.json")

# Load
loaded = load_contacts("contacts.json")
print(loaded)

Example 3: Extract data with regex

import re

def extract_emails(text):
    pattern = r"[\w.-]+@[\w.-]+\.\w+"
    return re.findall(pattern, text)

text = "Contact me at john@example.com or jane.doe@company.co.uk"
emails = extract_emails(text)
print(emails)  # ['john@example.com', 'jane.doe@company.co.uk']

Why This Matters

File I/O and exception handling are what separate learning exercises from real programs. Every professional program reads data from files or the internet, handles errors gracefully, and uses external libraries. Modules let you leverage thousands of hours of other people's work instead of writing everything yourself.

The most common beginner mistakes:

Forgetting to close files (use with — it's mandatory style)
Not handling file not found errors
Assuming regex patterns are simpler than they are
Catching generic Exception instead of specific errors
Not installing libraries with pip correctly

What's Next

In Part 8, the final part, we'll explore object-oriented programming — classes, inheritance, and polymorphism. OOP is how professional Python code is structured, and everything you've learned so far will come together.

This is Part 7 of an 8-part beginner Python series. Catch up on Part 1: Getting Started & Syntax, Part 2: Variables, Data Types & Numbers, Part 3: Strings & Booleans, Part 4: Operators & Control Flow, Part 5: Collections, and Part 6: Functions.

Python for Beginners — Part 6: Functions

Ramesh S — Tue, 23 Jun 2026 03:43:55 +0000

Part 6 of a beginner-friendly series on learning Python from scratch.

In Part 5, we learned to organize data with lists, dictionaries, and other collections. Now it's time to organize our code itself.

A function is a reusable block of code that performs a specific task. Instead of writing the same code multiple times, you write it once in a function, then call that function whenever you need it. This is the foundation of writing clean, maintainable programs.

Defining and Calling Functions

The basics

def greet():
    print("Hello, World!")

greet()  # Call the function

Use def to define a function. The function name is followed by parentheses and a colon. The indented block below is the function's body.

When you call the function (by typing its name with parentheses), Python runs the code inside it.

Functions with parameters

Most functions need information to work with. That's what parameters are for:

def greet(name):
    print(f"Hello, {name}!")

greet("Ramesh")   # Hello, Ramesh!
greet("Priya")    # Hello, Priya!

name is a parameter (placeholder). When you call greet("Ramesh"), name becomes "Ramesh" inside the function.

Multiple parameters:

def add(x, y):
    print(x + y)

add(5, 3)   # 8
add(10, 20) # 30

Return values

A function can calculate something and give the result back to you with return:

def add(x, y):
    return x + y

result = add(5, 3)
print(result)       # 8

The return statement stops the function and sends a value back. The caller can then use that value.

def greet(name):
    message = f"Hello, {name}!"
    return message

greeting = greet("Ramesh")
print(greeting)  # Hello, Ramesh!

A function can return multiple values as a tuple:

def get_user_info():
    return "Ramesh", 25, "Chennai"

name, age, city = get_user_info()
print(name, age, city)  # Ramesh 25 Chennai

Arguments: Positional vs Keyword

There are two ways to pass values to a function:

Positional arguments

Arguments are matched by position:

def describe(name, age):
    print(f"{name} is {age} years old")

describe("Ramesh", 25)  # Ramesh is 25 years old
describe(25, "Ramesh")  # 25 is Ramesh years old (wrong order, confusing)

Order matters.

Keyword arguments

You can use parameter names to be explicit:

def describe(name, age):
    print(f"{name} is {age} years old")

describe(age=25, name="Ramesh")  # Ramesh is 25 years old
describe(name="Ramesh", age=25)  # Ramesh is 25 years old (order doesn't matter)

Keyword arguments make code clearer and are less error-prone. Mix them freely:

describe("Ramesh", age=25)  # First positional, then keyword

Default Arguments

You can give parameters default values — they're optional:

def greet(name, greeting="Hello"):
    return f"{greeting}, {name}!"

print(greet("Ramesh"))              # Hello, Ramesh!
print(greet("Ramesh", "Hi"))        # Hi, Ramesh!
print(greet("Ramesh", greeting="Hey"))  # Hey, Ramesh!

If the caller doesn't provide greeting, it defaults to "Hello".

Important rule: Parameters with defaults must come after parameters without defaults:

# Correct
def add(x, y, verbose=False):
    result = x + y
    if verbose:
        print(f"{x} + {y} = {result}")
    return result

# Wrong — SyntaxError
def add(x=0, y):
    return x + y

*args — Variable Number of Arguments

Sometimes you want a function to accept any number of arguments. Use *args:

def add_many(*numbers):
    total = 0
    for num in numbers:
        total += num
    return total

print(add_many(1, 2, 3))           # 6
print(add_many(1, 2, 3, 4, 5))     # 15
print(add_many())                  # 0 (no arguments)

*args (the name args is conventional) collects all extra arguments into a tuple. The * unpacks them.

def print_all(*items):
    for item in items:
        print(item)

print_all("apple", "banana", "cherry", 42)
# Prints each on its own line

**kwargs — Keyword Arguments as Dictionary

Similar to *args, use **kwargs to accept any number of keyword arguments:

def make_profile(**info):
    for key, value in info.items():
        print(f"{key}: {value}")

make_profile(name="Ramesh", age=25, city="Chennai")
# Output:
# name: Ramesh
# age: 25
# city: Chennai

**kwargs (convention) collects keyword arguments into a dictionary.

Combining everything

You can use *args and **kwargs together:

def my_function(required, *args, default_arg="default", **kwargs):
    print(f"Required: {required}")
    print(f"Args: {args}")
    print(f"Default: {default_arg}")
    print(f"Kwargs: {kwargs}")

my_function(1, 2, 3, 4, default_arg="custom", extra1="value1", extra2="value2")

# Output:
# Required: 1
# Args: (2, 3, 4)
# Default: custom
# Kwargs: {'extra1': 'value1', 'extra2': 'value2'}

Order: positional, *args, keyword defaults, **kwargs.

Scope and Variable Lifetime

Variables have scope — the region of code where they exist and are accessible.

Local scope

Variables created inside a function only exist inside that function:

def greet():
    message = "Hello"  # Local variable
    print(message)

greet()           # Hello
print(message)    # NameError — message doesn't exist here

Global scope

Variables created outside functions are global:

message = "Hello"  # Global variable

def greet():
    print(message)  # Can access global variables

greet()    # Hello
print(message)  # Hello

Modifying global variables

Be careful — inside a function, assignment creates a local variable:

count = 0

def increment():
    count = count + 1  # UnboundLocalError — trying to use local before assignment
    return count

increment()

To modify a global variable inside a function, use global:

count = 0

def increment():
    global count
    count = count + 1
    return count

increment()
print(count)  # 1

Tip: Generally, avoid modifying global variables. It makes code hard to understand. Instead, pass values in and return values out.

Lambda Functions — Quick Throwaway Functions

A lambda is a tiny anonymous function, useful for one-liners:

square = lambda x: x ** 2
print(square(5))  # 25

Syntax: lambda parameters: expression

Lambda functions are usually passed to other functions. For example, sorted() can take a function that determines the sort order:

people = [
    {"name": "Ramesh", "age": 25},
    {"name": "Priya", "age": 20},
    {"name": "Arun", "age": 30}
]

# Sort by age
sorted_by_age = sorted(people, key=lambda person: person["age"])
print(sorted_by_age)
# [{'name': 'Priya', 'age': 20}, {'name': 'Ramesh', 'age': 25}, {'name': 'Arun', 'age': 30}]

Or with map() to transform a list:

numbers = [1, 2, 3, 4, 5]
squared = list(map(lambda x: x ** 2, numbers))
print(squared)  # [1, 4, 9, 16, 25]

Lambda is elegant for simple operations. For anything complex, write a proper function.

Recursion — Functions Calling Themselves

A recursive function calls itself. It's powerful for solving problems that repeat the same pattern at smaller scales.

Every recursive function needs a base case (when to stop) and a recursive case (how to shrink the problem):

def countdown(n):
    # Base case
    if n == 0:
        print("Blastoff!")
        return

    # Recursive case
    print(n)
    countdown(n - 1)

countdown(5)
# Output:
# 5
# 4
# 3
# 2
# 1
# Blastoff!

Without a base case, the function recurses infinitely and crashes:

def bad_countdown(n):
    print(n)
    bad_countdown(n - 1)  # Never stops!

bad_countdown(5)  # RecursionError: maximum recursion depth exceeded

Classic example: Factorial

def factorial(n):
    # Base case
    if n == 0 or n == 1:
        return 1

    # Recursive case
    return n * factorial(n - 1)

print(factorial(5))  # 120 (5 * 4 * 3 * 2 * 1)

Recursion is elegant but can be slow and memory-intensive. Use it when the problem naturally breaks into recursive patterns (like tree structures), not for simple loops.

Generators and Iterators

A generator is a function that yields values one at a time, instead of returning them all at once. Use yield:

def count_up_to(n):
    i = 1
    while i <= n:
        yield i
        i += 1

for num in count_up_to(5):
    print(num)

# Output:
# 1
# 2
# 3
# 4
# 5

The function pauses at yield and resumes where it left off. This is memory-efficient for large datasets:

# Without generator — creates entire list in memory
def range_list(n):
    result = []
    for i in range(n):
        result.append(i)
    return result

# With generator — creates values on-demand
def range_gen(n):
    for i in range(n):
        yield i

# Both work with for loops, but generator is more efficient
for num in range_list(1000000):  # Creates 1 million item list
    print(num)

for num in range_gen(1000000):   # Creates values as needed
    print(num)

Generators are a more advanced topic — understand them conceptually now; you'll use them more as you progress.

Practical Examples

Example 1: Simple calculator

def add(x, y):
    return x + y

def subtract(x, y):
    return x - y

def multiply(x, y):
    return x * y

def divide(x, y):
    if y == 0:
        return "Cannot divide by zero"
    return x / y

print(add(10, 5))       # 15
print(divide(10, 0))    # Cannot divide by zero

Example 2: Processing collections

def find_max(numbers):
    if len(numbers) == 0:
        return None

    max_num = numbers[0]
    for num in numbers:
        if num > max_num:
            max_num = num
    return max_num

print(find_max([3, 7, 2, 9, 1]))  # 9

Example 3: Flexible greeting

def create_greeting(*names, greeting="Hello", punctuation="!"):
    message = f"{greeting}, {', '.join(names)}{punctuation}"
    return message

print(create_greeting("Ramesh", "Priya"))
# Hello, Ramesh, Priya!

print(create_greeting("Alice", "Bob", greeting="Hi", punctuation="?"))
# Hi, Alice, Bob?

Why This Matters

Functions are how you stop repeating yourself. Instead of copying the same code 10 times, you write it once, call it 10 times. This saves time, prevents bugs, and makes changes easier.

The most common beginner mistakes:

Forgetting parentheses when calling a function
Using return to print (they're different — one sends a value back, one displays it)
Trying to use variables defined inside a function outside of it
Infinite recursion (forgetting the base case)
Confusing *args with * unpacking operator

What's Next

In Part 7, we explored with modules, errors, and files — using other people's code, handling problems gracefully, and reading/writing data to disk. Functions you write will often read or write files.

This is Part 6 of an 8-part beginner Python series. Catch up on Part 1: Getting Started & Syntax, Part 2: Variables, Data Types & Numbers, Part 3: Strings & Booleans, Part 4: Operators & Control Flow, and Part 5: Collections.