DEV Community: Om Kolhapure

Week 9: Finally, I understand the Web.

Om Kolhapure — Sun, 05 Jul 2026 09:48:29 +0000

Eight weeks of Python. Then Week 9 started and there wasn't a single .py file in sight.

That's not a mistake — it's the plan. Understanding how the web actually works has been on the roadmap since Month 1, and Week 9 was the week to finally build it: HTML, CSS, and JavaScript, from a bare page to a dynamic to-do list talking to a real API. New repo, new language, same daily habit.

Here's how it went.

Day 57 — HTML Structure: A Real Portfolio Page

The project for the week: a personal portfolio page. Day 57 was just the skeleton — semantic HTML, no styling at all.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>My Portfolio</title>
</head>
<body>
    <header>
        <h1>Om Kolhapure</h1>
        <nav>
            <ul>
                <li><a href="#home">Home</a></li>
                <li><a href="#projects">Projects</a></li>
                <li><a href="#contact">Contact</a></li>
            </ul>
        </nav>
    </header>

    <main>
        <section id="home">
            <h2>Education</h2>
            <p>
                I am currently pursuing my <strong>Bachelor's in Computer Science and Engineering</strong>
                from Walchand Institute of Technology. In my first year, I scored 9.61 CGPA.
            </p>

            <h2>My Interests</h2>
            <p>
                I chose Computer Science because I was always curious about how computers work,
                how different apps function, and so on. Now I am interested in Artificial Intelligence,
                Machine Learning, and Cloud Computing.
            </p>
        </section>

        <section id="projects">
            <h2>My Projects</h2>
            <p>
                I have done many projects; all are present on my 
                <a href="https://github.com/Omk4314/progress-on-python.git">GitHub</a>.
                My most real-world project was a 
                <a href="https://github.com/Omk4314/progress-on-python/tree/main/url-shortner">URL Shortener</a>.
                It takes a long URL from the user and makes it short so that when the user clicks on it,
                they are redirected to the same page as the long URL.
            </p>
            <p>
                The main problem I faced was assigning different codes to different long URLs and keeping track of them.
            </p>
        </section>

        <section id="contact">
            <h2>Contact Me</h2>
            <p>LinkedIn: <a href="https://www.linkedin.com/in/om-kolhapure-0572603b6">linkedin.com/in/om-kolhapure</a></p>
        </section>
    </main>
</body>
</html>

The word that kept coming up in the lesson was semantic. <header>, <nav>, <main>, <section> — these aren't just containers, they tell a screen reader (or any tool parsing the page) what each part of the page actually is. A <div> says nothing. A <nav> says "this is navigation."

The <ul> inside <nav> for the menu links felt odd at first — a navigation menu is a list of links. Once that clicked, semantic HTML stopped feeling like extra rules and started feeling like describing the page honestly.

And there it is — my Month 1–2 Python work getting linked from inside this very page. The URL shortener project earned its place as the portfolio's showcase piece.

Day 58 — CSS Fundamentals: Making It Actually Look Like Something

Day 58 took the bare HTML and gave it real styling — flexbox, responsive breakpoints, and a design system built from scratch:

* {
    box-sizing: border-box;
}
body {
    margin: 0;
    font-family:sans-serif;
    line-height: 1.6;
}
ul {
    list-style: none;
    padding: 0;
    margin: 0;
}
a {
    text-decoration: none;
    color: inherit;
}
header {
    display: flex;
    justify-content: flex-start;
    align-items: center;
    gap: 20px;
}
nav ul {
    display: flex;
    gap: 20px;
}
nav a {
    display: inline-block;
    padding: 0.5rem 1rem;
}
nav a:hover {
    background-color: red;
}
main {
    max-width: 700px;
    margin:0 auto;
    padding: 2rem;
}
section {
    padding: 2rem 0;
    border-bottom: 20px;
}
header {
    flex-direction: column;
    text-align: center;
    gap: 1rem;
}
@media (min-width: 600px) {
    header {
        flex-direction: row;
        /* How do you push nav to the right? */
    }
}
main {
    padding: 1rem;
}

@media (min-width: 600px) {
    main {
        padding: 2rem;
    }
}
#contact a {
    color:#0077b5;
}
#contact a:hover {
    text-decoration: underline;
}
strong {
    color: #2c3e50;
}
h2 {
    border-bottom: 2px solid #333;
    padding-bottom: 0.5rem;
}

Two things clicked hard on this day.

box-sizing: border-box on the universal selector — a rule I'd read about but didn't understand the point of until I removed it once by accident and watched every element's padding blow past its intended width. With border-box, padding and border get counted inside the element's declared width instead of added on top. Every layout tutorial assumes this rule exists. Now I know why.

@media (min-width: 600px) — my first real media query. Mobile-first thinking: define the small-screen layout as the default (header stacked in a column), then override it for wider screens (flex-direction: row). That inversion — style for mobile first, then add rules for bigger screens — was the opposite of how I assumed CSS worked.

I left a comment in the CSS mid-lesson that I never deleted: /* How do you push nav to the right? */. That's an honest artifact of learning in public — a question I hadn't answered yet, sitting right there in the file, later solved with flexbox's justify-content: space-between once I understood the property better.

Day 59 — JavaScript Basics: A Dark Mode Toggle

Day 59 added the first sliver of interactivity — a dark mode button that actually works:

const toggleBtn = document.getElementById("theme-toggle");
toggleBtn.addEventListener("click", function() {
    document.body.classList.toggle("dark-mode");
    if (document.body.classList.contains("dark-mode")) {
        toggleBtn.innerText = "Light Mode";
    }
    else {
        toggleBtn.innerText = "Dark Mode";
    }
});

Paired with dark-mode-specific CSS rules:

body.dark-mode {
    background-color: #1a1a1a;
    color: #f0f0f0;
}

.dark-mode a {
    color: #4dabf7;
}

.dark-mode strong {
    color: #a5d8ff;
}

.dark-mode h2 {
    border-bottom-color: #555;
}

.dark-mode nav a:hover {
    background-color: #333;
}

Three ideas landed at once here:

document.getElementById() — JavaScript reaching into the page to grab a specific element by its id. This is the JS equivalent of Python's input() — the moment the program starts responding to the actual page instead of just running blind.
classList.toggle("dark-mode") — adds the class if it's missing, removes it if it's present. One line does what would otherwise be an if/else on its own.
CSS reacting to JS. The .dark-mode class doesn't do anything by itself — it's just a hook. All the actual dark-mode styling lives in CSS, keyed off a class that JavaScript flips on and off. Separation of concerns, made concrete: JavaScript handles behaviour, CSS handles appearance, and they meet at exactly one point — a class name.

Coming from Python's if/else, writing toggleBtn.addEventListener("click", function() {...}) felt inside-out at first — you're not calling the function, you're handing it to the browser and saying "run this whenever a click happens." Event-driven thinking is a different rhythm than the top-to-bottom scripts Month 1 and 2 were full of.

Day 60 — DOM Manipulation: A Real To-Do List

Day 60 was the biggest jump of the week — a fully dynamic to-do list: add tasks, mark them complete, delete them, move completed tasks to their own section, all without a single page reload.

<section aria-labelledby="add-task-heading">
    <h2 id="add-task-heading">Add a New Task</h2>
    <form action="#" method="post">
        <label for="task-input">What do you need to do?</label>
        <input 
            type="text" 
            id="task-input" 
            name="task" 
            placeholder="Enter your task here..." 
            required
            minlength="1"
            maxlength="200"
        >
        <button type="submit">Add Task</button>
    </form>
</section>

And the JavaScript driving all of it:

document.addEventListener('DOMContentLoaded', function () {
    const taskForm = document.querySelector('form');
    const taskInput = document.getElementById('task-input');
    const taskList = document.querySelector('ul');
    const completedSection = document.querySelector('section[aria-labelledby="completed-heading"]');

    let taskCounter = 3;

    function createTaskElement(taskText) {
        taskCounter++;
        const li = document.createElement('li');
        li.setAttribute('data-task-id', taskCounter);

        const checkbox = document.createElement('input');
        checkbox.type = 'checkbox';
        checkbox.id = 'task-' + taskCounter;
        checkbox.name = 'task-' + taskCounter;

        const label = document.createElement('label');
        label.setAttribute('for', 'task-' + taskCounter);
        label.textContent = taskText;

        const deleteBtn = document.createElement('button');
        deleteBtn.type = 'button';
        deleteBtn.setAttribute('aria-label', 'Delete task: ' + taskText);
        deleteBtn.textContent = 'Delete';

        li.appendChild(checkbox);
        li.appendChild(label);
        li.appendChild(deleteBtn);

        deleteBtn.addEventListener('click', function () {
            deleteTask(li);
        });

        checkbox.addEventListener('change', function () {
            handleTaskToggle(checkbox, label, li);
        });

        return li;
    }

    function addTask(event) {
        event.preventDefault();
        const taskText = taskInput.value.trim();
        if (taskText === '') {
            return;
        }
        const newTask = createTaskElement(taskText);
        taskList.appendChild(newTask);
        taskInput.value = '';
        taskInput.focus();
    }

    function deleteTask(taskElement) {
        const isCompleted = taskElement.querySelector('input[type="checkbox"]').checked;
        if (isCompleted) {
            const completedList = document.getElementById('completed-task-list');
            if (completedList) {
                completedList.removeChild(taskElement);
                checkEmptyCompleted();
            }
        } else {
            taskList.removeChild(taskElement);
        }
    }

    function handleTaskToggle(checkbox, label, taskElement) {
        if (checkbox.checked) {
            label.style.textDecoration = 'line-through';
            label.style.opacity = '0.6';
            moveToCompleted(taskElement);
        } else {
            label.style.textDecoration = 'none';
            label.style.opacity = '1';
            taskList.appendChild(taskElement);
            checkEmptyCompleted();
        }
    }

    function moveToCompleted(taskElement) {
        let completedList = document.getElementById('completed-task-list');
        if (!completedList) {
            completedList = document.createElement('ul');
            completedList.id = 'completed-task-list';
            completedSection.appendChild(completedList);
            const emptyMsg = completedSection.querySelector('p');
            if (emptyMsg) {
                emptyMsg.remove();
            }
        }
        completedList.appendChild(taskElement);
    }

    function checkEmptyCompleted() {
        const completedList = document.getElementById('completed-task-list');
        if (completedList && completedList.children.length === 0) {
            const emptyMsg = document.createElement('p');
            emptyMsg.textContent = 'No completed tasks yet.';
            completedSection.appendChild(emptyMsg);
            completedList.remove();
        }
    }

    function setupExistingTasks() {
        const existingTasks = taskList.querySelectorAll('li');
        existingTasks.forEach(function (taskElement) {
            const checkbox = taskElement.querySelector('input[type="checkbox"]');
            const label = taskElement.querySelector('label');
            const deleteBtn = taskElement.querySelector('button');

            deleteBtn.addEventListener('click', function () {
                deleteTask(taskElement);
            });
            checkbox.addEventListener('change', function () {
                handleTaskToggle(checkbox, label, taskElement);
            });

            if (checkbox.checked) {
                label.style.textDecoration = 'line-through';
                label.style.opacity = '0.6';
                moveToCompleted(taskElement);
            }
        });
    }

    taskForm.addEventListener('submit', addTask);
    setupExistingTasks();
});

The pattern that made everything else make sense: document.createElement() builds pieces, .appendChild() assembles them, event listeners get attached before the element ever touches the page. createTaskElement() builds an entire <li> — checkbox, label, delete button — completely in memory first, wires up its own delete and toggle behaviour, and only then gets appended to the visible list.

event.preventDefault() in addTask() was a small but essential line — without it, submitting the form does what HTML forms do by default: reload the page and lose everything. That one line is the difference between a static form and an actual single-page interaction.

setupExistingTasks() deserves a callout too — it attaches the same event listeners to the three tasks that were already hardcoded in the HTML, so the "starter" tasks behave identically to ones added dynamically. Nice touch for consistency.

Day 61 — Fetch API: Talking to a Real Server

Day 61 replaced the in-memory to-do list with one backed by a real API — jsonplaceholder.typicode.com, a free fake REST API for testing exactly this kind of thing.

const API_BASE = 'https://jsonplaceholder.typicode.com';
const MAX_RETRIES = 3;
const BASE_RETRY_DELAY = 1000;
const USER_ID = 1;

let activeAbortController = null;

async function apiRequest(endpoint, options = {}) {
    const {
        method = 'GET',
        body = null,
        retries = MAX_RETRIES,
        ...fetchOptions
    } = options;

    if (activeAbortController) {
        activeAbortController.abort();
    }

    const abortController = new AbortController();
    activeAbortController = abortController;

    const url = `${API_BASE}${endpoint}`;
    const config = {
        method,
        headers: {
            'Content-Type': 'application/json',
            ...fetchOptions.headers
        },
        signal: abortController.signal,
        ...fetchOptions
    };

    if (body) {
        config.body = JSON.stringify(body);
    }

    let lastError;

    for (let attempt = 0; attempt <= retries; attempt++) {
        try {
            const response = await fetch(url, config);

            if (!response.ok) {
                throw new Error(`HTTP ${response.status}: ${response.statusText}`);
            }

            const contentType = response.headers.get('content-type');
            const data = (contentType && contentType.includes('application/json'))
                ? await response.json()
                : null;

            if (activeAbortController === abortController) {
                activeAbortController = null;
            }

            return data;

        } catch (error) {
            lastError = error;

            if (error.name === 'AbortError') {
                throw error;
            }

            if (error.message && error.message.startsWith('HTTP 4')) {
                throw error;
            }

            if (attempt < retries) {
                const delay = BASE_RETRY_DELAY * Math.pow(2, attempt);
                await new Promise(resolve => setTimeout(resolve, delay));
            }
        }
    }

    if (activeAbortController === abortController) {
        activeAbortController = null;
    }

    throw lastError;
}

async function getTodos() {
    return apiRequest(`/todos?userId=${USER_ID}&_limit=5`, {
        preventRace: true
    });
}

async function addTodo(title) {
    return apiRequest('/todos', {
        method: 'POST',
        body: {
            title,
            completed: false,
            userId: USER_ID
        },
        preventRace: false
    });
}

async function deleteTodo(id) {
    return apiRequest(`/todos/${id}`, {
        method: 'DELETE',
        preventRace: false
    });
}

async function updateTodo(id, updates) {
    return apiRequest(`/todos/${id}`, {
        method: 'PATCH',
        body: updates,
        preventRace: false
    });
}

This file is doing more than a basic fetch tutorial ever shows, and each extra piece exists for a real reason:

async/await — reading top to bottom like normal code, even though fetch() is asynchronous under the hood. This is JavaScript's answer to the same problem Python's try/except solves for unreliable operations, just with a different shape.
Retry with exponential backoff — BASE_RETRY_DELAY * Math.pow(2, attempt) means each retry waits longer than the last (1s, 2s, 4s...). A flaky network shouldn't mean an instant failure.
AbortController — cancelling an in-flight request if a new one starts before the old one finishes. This stops a slow, stale request from overwriting fresher data — a real bug that's easy to introduce and easy to miss until it happens.
Distinguishing 4xx errors from network errors — if (error.message && error.message.startsWith('HTTP 4')) skips retrying on client errors like "404 Not Found," because retrying a request that's wrong by definition just wastes time. Only genuinely flaky failures get retried.

The rest of newScript.js reuses the exact same DOM manipulation functions from Day 60 — moveToCompleted(), checkEmptyCompleted() — but now every checkbox toggle and delete button calls the API first and only updates the DOM after a successful response, with setLoading() disabling the form while a request is in flight so nothing gets submitted twice.

Watching real data load from a live URL into the same to-do list interface from Day 60 was the moment the whole week's arc paid off — static HTML, to styled HTML, to interactive HTML, to an HTML page that talks to the internet.

Day 62 — Weather Dashboard: Still In Progress

The plan for Day 62 is a weather dashboard pulling live data from the OpenWeatherMap API, showing current conditions plus a 5-day forecast — the same Fetch API skills from Day 61, applied to a second, independent API. That project is still being built as this post goes out, and it'll get proper coverage once it's finished and pushed.

📁 What I Built This Week

Project	File	Concepts Used
Portfolio (structure)	`portfolio.html`	Semantic HTML, accessibility basics
Portfolio (styled)	`css-portfolio/styles.css`, `styledPortfolio.html`	Flexbox, media queries, `box-sizing`
Dark Mode Toggle	`css-portfolio/script.js`	DOM selection, `classList.toggle()`, event listeners
To-Do List (local)	`Todo-list/todo.html`, `style.css`, `script.js`	Dynamic DOM creation, form handling, `event.preventDefault()`
To-Do List (API-backed)	`Todo-list/newScript.js`	`fetch`, `async/await`, retry logic, `AbortController`

All the code is on GitHub — brand new repo, same daily habit:
👉 github.com/Omk4314/Progress-on-HTML-CSS-JS

What Actually Clicked This Week

Semantic HTML describes the page, it doesn't just structure it. <nav> and <section> communicate meaning that a stack of <div>s never could.
box-sizing: border-box should probably always be on. I understood why the moment I saw a layout break without it.
CSS and JavaScript meet at a class name. The dark mode toggle taught me that JS shouldn't be reaching in to change styles directly — it should flip a class, and let CSS own the actual appearance.
document.createElement() + appendChild() is how dynamic pages are actually built. Nothing on the page is fixed — it's all just JavaScript assembling pieces and dropping them in.
Fetch code that's actually reliable is more than just fetch(). Retry logic, abort controllers, and distinguishing error types are the difference between a demo and something that survives a flaky connection.
This felt like starting over, and that was fine. Eight weeks of Python confidence didn't transfer directly to CSS flexbox — but the habit of building daily, reading errors carefully, and testing as I go transferred completely.

What I Want to Learn Next

Week 10 is already planned around finishing the weather dashboard and going further into the front end:

Finish the weather dashboard — real API, current + forecast data, proper error states
CSS Grid — flexbox got me through this week, but grid is the tool for genuinely two-dimensional layouts
More async patterns — Promise.all(), handling multiple simultaneous requests
Maybe a small framework preview — enough to see what problems React or similar tools are actually solving

Nine weeks of daily practice, and this week was proof that the habit is the real skill — not any single language. Same discipline, brand new syntax, and the terminal-fear-is-gone feeling from Month 1 showed up again by Wednesday.

If you've made the jump from a backend language into web basics, I'd love to hear what clicked fastest for you — and what didn't.

See you in Week 10. 🌐

Week 9 complete. Different language, same daily commit.

Month 2: From OOP to Algorithms.

Om Kolhapure — Mon, 29 Jun 2026 05:25:28 +0000

Month 1 was about learning the language.

Month 2 was about learning to think like a programmer.

The difference shows up everywhere. Month 1 me wrote functions because a lesson told me to. Month 2 me reaches for a class because the data has relationships, or a stack because the problem is fundamentally "last thing in, first thing out." This month had four weeks, each with a completely different texture — deep OOP, a full real-world project shipped publicly, a hard pivot into algorithms, and finally building data structures from scratch. Here's the whole story.

The Structure: Four Very Different Weeks

Week	Theme	Days	Energy
Week 5	OOP Deep Dive	29–34	Conceptual — learning to model the world in code
Week 6	Real Project	36–41	Practical — designing, shipping, and defending one project
Week 7	DSA: Arrays & Hashing	43–48	New territory — algorithms instead of applications
Week 8	Stacks, Queues, Linked Lists	50–55	Foundational — building the structures themselves

Two brand-new GitHub repos exist because of this month. progress-on-python kept growing with OOP and project work. neetcode-submissions was born in Week 7 specifically to hold algorithm practice — a sign that DSA started to feel like its own distinct skill, deserving its own home.

Week 5 — OOP Deep Dive

Theme: Stop writing functions. Start modeling things.

What I learned

Classes, __init__, self, instance attributes
Inheritance and super() — sharing behaviour between related classes
Encapsulation with @property getters and setters
Dunder methods — __str__, __repr__, __eq__
Composition vs inheritance — the "is-a" vs "has-a" question

What I built

Project	Highlight
Bank Account	Deposit, withdraw, transfer, full transaction history per account
CheckingAccount / SavingsAccount	Inheritance, `super().__init__()`, overdraft fees, interest
Dunder Methods	`print(account)` returning `BankAccount(Alice, 85.0)` instead of a memory address
Library System	Composition — `Book`, `Member`, `Loan`, `Library` as four separate classes
Task Manager	Walrus operator in regex property setters, `date.today()` overdue checks, 8 structured tests

The moment that clicked

The library system's Loan class — capturing the relationship between a Book and a Member as its own object, rather than cramming that logic into either one. That's when composition stopped being a vocabulary word and became a design instinct.

Biggest surprise

OOP is about grouping, not just syntax. Wrapping related behaviour into a class doesn't change what code does — it changes how it's organised. That distinction reframed how I think about every program since.

Week 6 — One Project, One Week

Theme: Design it. Build it. Ship it. Defend it. Improve it.

What I learned

Writing a design document before any code — data model, API shape, edge cases
Building a complete CLI tool with JSON persistence
Tracking analytics in CSV with a read-modify-rewrite pattern
Writing a README for strangers
Asking for public code review — and actually using the feedback

What I built

A URL shortener. One project, six days, fully designed before being built:

Design.txt — six sections answering what it does, the data model, the "API," storage choice, code generation strategy, and edge cases
url_shortner.py — an Url class handling shortening, deduplication, and visit tracking
clicked_report.csv — analytics tracking how many times each URL was visited
A public README with real usage examples
Public sharing on Reddit and Discord, three+ code reviews, and a real bug fix afterward

The moment that clicked

Writing the design doc before touching the editor. The line "I will use Python's random module to generate 6 characters... I will check if the code already exists... if the code exists I will generate it again" became, almost word for word, the generate_code() method a day later. Planning wasn't separate from coding — it was coding in plain English first.

Biggest surprise

Public code review wasn't the ordeal I expected. A reviewer caught a real bug — most_clicked() was calling self.visit() twice in some cases, double-prompting the user. Strangers online were more useful for catching that than another week of solo work would have been.

Week 7 — A Hard Pivot Into Algorithms

Theme: Stop building. Start solving.

What I learned

Big O notation — naming the "feels slow" instinct I already had
Hash maps and sets as the "trade memory for speed" pattern
Two pointers — and recognising sorted input as a signal to use them
Sliding window — never re-scanning data you've already passed
A brand-new repo, neetcode-submissions, just for this kind of work

What I built

Problem	Pattern
Two Sum	Hash map
Contains Duplicate	Set
Valid Anagram	Hash map counting
Group Anagrams	Canonical sorted key
Top K Frequent Elements	Bucket sort (no sorting algorithm needed)
Valid Palindrome	Two pointers
Two Sum II	Two pointers (sorted input)
3Sum	Two pointers nested inside a loop
Best Time to Buy/Sell Stock	Running minimum
Longest Substring Without Repeating Characters	Sliding window

The moment that clicked

Revisiting the Week 6 URL shortener's if code not in urls: line and realising it was already O(1) because urls was a dictionary — a design decision I'd made for convenience back in Week 6 turned out to already be the efficient choice. Naming why it was right, using Big O, was the real Week 7 lesson.

Biggest surprise

Mock-solving problems under a timer on Day 48 revealed the gap between "I understand this" and "I can rebuild this from a blank file." The patterns that came back fastest were the ones I'd genuinely internalised, not just followed along with once.

Week 8 — Building the Structures Themselves

Theme: Stop using built-in types. Build the data structures from scratch.

What I learned

Stacks (LIFO) and queues (FIFO) implemented from raw Python lists and deque
Linked lists — my first pointer-based structure with no array underneath
The dummy node pattern for removing special cases in list problems
Fast and slow pointers for "distance from the end" problems
How stack thinking quietly shows up in completely unrelated problems

What I built

Project	Highlight
Valid Parentheses	A stack matching brackets, with an odd-length early exit
Stack Using Queues	Implementing one structure's behaviour using only the other's primitives
Reverse Linked List	Three pointers (`prev`, `curr`, `nxt`) flipping arrows one at a time
Merge Two Sorted Lists	The dummy node pattern removing every "first node" special case
Remove Nth Node From End	Fast and slow pointers with a fixed gap, solved in one pass
Browser History Tracker	A single pointer + list quietly acting as two stacks glued together

The moment that clicked

The browser history tracker's visit_site() truncating everything ahead of the current pointer before adding a new entry — exactly how real browsers discard "forward" history once you branch into a new page. That one line of code, self.history = self.history[:self.pointer + 1], is Day 50's stack thinking showing up in Day 54's project without ever mentioning a stack.

Biggest surprise

Drawing pointer diagrams on paper before writing the Reverse Linked List function made the logic obvious in a way that reading code never did. Two minutes of sketching saved twenty minutes of confusion.

Everything I Built in Month 2

#	Project	Week	Key Concepts
1	Bank Account	5	`__init__`, `@property`, transaction history
2	CheckingAccount / SavingsAccount	5	Inheritance, `super()`, overdraft, interest
3	Dunder Methods	5	`__str__`, `__repr__`, `__eq__`
4	Library System	5	Composition, 4-class design
5	Task Manager	5	Walrus operator, regex setters, 8 tests
6	URL Shortener	6	Design doc, OOP, JSON storage, CSV analytics
7	Two Sum	7	Hash map
8	Contains Duplicate	7	Set
9	Valid Anagram	7	Hash map counting
10	Group Anagrams	7	Canonical key
11	Top K Frequent Elements	7	Bucket sort
12	Valid Palindrome	7	Two pointers
13	Two Sum II	7	Two pointers
14	3Sum	7	Two pointers + dedup
15	Best Time to Buy/Sell Stock	7	Running minimum
16	Longest Substring Without Repeating Characters	7	Sliding window
17	Valid Parentheses	8	Stack
18	Stack Using Queues	8	Stack/queue relationship
19	Reverse Linked List	8	Pointer reversal
20	Merge Two Sorted Lists	8	Dummy node
21	Remove Nth Node From End	8	Fast & slow pointers
22	Browser History Tracker	8	Stack logic, pointer state

All of it is on GitHub:
👉 github.com/Omk4314/progress-on-python
👉 github.com/Omk4314/neetcode-submissions

What Changed in Month 2

How I design before I build. Week 6's design doc was the first time planning happened entirely separate from coding. By Week 8, sketching pointer diagrams on paper before writing linked list functions had become a habit, not an assignment.

How I think about efficiency. Month 1 me had a vague sense that some code "felt slow." Month 2 me can say why — O(1) dictionary lookups versus O(n) list scans, two pointers beating a hash map when the input is sorted, sliding windows avoiding redundant re-scans.

How I relate classes to each other. Inheritance for "is-a," composition for "has-a." That single distinction, learned in Week 5's library system, now shapes every design decision before a line of code gets written.

How I receive feedback. Week 6 was the first time I shared code publicly and asked strangers to find problems with it. The bug they found — a double-call in most_clicked() — was real, and fixing it based on someone else's eyes was more valuable than another week of solo debugging would have been.

How fast old patterns come back. Week 7's Day 48 mock test was uncomfortable. Week 8's Day 55 review of the same kind of exercise was fast. That gap is the clearest evidence that the patterns from this month are becoming reflexes rather than lessons.

What I'd Tell Myself at the Start of Month 2

Write the design doc first, even for small projects. The URL shortener's Design.txt made every day of building faster because the hard thinking happened once, up front.
A new kind of problem deserves a new repo. Splitting neetcode-submissions away from progress-on-python wasn't bureaucracy — it made it obvious which skill was being practiced on any given day.
Ask for code review before you feel ready. The feedback on the URL shortener was more useful because the code wasn't perfect yet.
Sketch before you code, especially for pointers. Linked lists are a visual problem wearing a syntax costume.
Re-solving old problems is the real test. Not whether you can follow a solution, but whether you can rebuild it cold, days later, without panic.

What's Next

Month 3 has clear targets already taking shape from Week 8's closing thoughts:

Trees and recursion — the next data structure family, and the first one that forces recursive thinking
Binary search trees — ordered structures with their own traversal rules
Heaps and priority queues — a natural extension of this month's queue work
Bigger, multi-class projects — combining OOP from Week 5 with the algorithmic thinking from Weeks 7 and 8

Two months down. The foundation isn't just "I know Python syntax" anymore — it's "I can model a problem, choose the right structure, and explain why." That's a different kind of confidence than the one I had at the end of Month 1.

If you're following along, building your own projects, or grinding the same NeetCode list — drop a comment. I'd genuinely like to see what Month 2 looked like for you.

See you in Month 3. 🐍

8 weeks. 22 projects and solutions. Two repos. One streak still going.

What I Learned in Week 8 of Python — Stacks, Queues & Linked Lists

Om Kolhapure — Mon, 29 Jun 2026 05:22:04 +0000

Week 7 was hash maps and two pointers — patterns that lean on Python's built-in dict, set, and list.

Week 8 was different. This week I built the data structures themselves. Stacks, queues, linked lists — implementing them from scratch before using them to solve real problems. By the end of the week I had a browser history tracker with working back and forward buttons, built on the same logic LeetCode problems made me practice all week.

Month 2 is done. Here's how it closed out.

Day 50 — Stacks: LIFO, From Scratch

A stack is the simplest data structure with a personality: last in, first out. Whatever you added most recently is the first thing you remove. Think of a stack of plates — you take from the top.

Implementing one from scratch made that personality concrete:

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

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

    def pop(self):
        if not self.items:
            return None
        return self.items.pop()

    def peek(self):
        if not self.items:
            return None
        return self.items[-1]

    def is_empty(self):
        return len(self.items) == 0

Python's list.append() and list.pop() already behave exactly like a stack at the end — that's not a coincidence, it's the same underlying behaviour. Wrapping them in a class just gives the operations names that match the concept: push, pop, peek.

Then came the problem that made stacks click for real: Valid Parentheses. Given a string of brackets, determine if every opening bracket has a matching closing bracket in the right order.

class Solution:
    def isValid(self, s: str) -> bool:
        mp = {']': '[', ')': '(', '}': '{'}
        stack = []
        if len(s)%2 != 0:
            return False
        for c in s:
            if stack and c in mp and mp[c] == stack[-1]:
                stack.pop()
            else:
                stack.append(c)
        return len(stack) == 0

The logic: scan left to right. Every opening bracket gets pushed onto the stack. Every closing bracket checks if it matches whatever's currently on top of the stack — if it does, pop it off. If the string is valid, the stack empties out completely by the end.

The odd-length check (len(s)%2 != 0) is a quick rejection before doing any real work — an unbalanced string can never have matching pairs if its length is odd. Small optimisation, but it's the kind of thing that starts feeling natural once you've internalised what the problem actually requires.

What clicked: a stack is the exact right structure here because "most recently opened bracket needs to close first" is last-in-first-out, word for word.

Day 51 — Queues: FIFO, and Stack-via-Queue

A queue is a stack's opposite: first in, first out. Whoever's been waiting longest gets served first — like an actual queue of people.

from collections import deque

class Queue:
    def __init__(self):
        self.items = deque()

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

    def dequeue(self):
        if not self.items:
            return None
        return self.items.popleft()

    def peek(self):
        if not self.items:
            return None
        return self.items[0]

    def is_empty(self):
        return len(self.items) == 0

Using deque instead of a plain list here was deliberate — list.pop(0) is O(n) because every remaining element has to shift left. deque.popleft() is O(1). For a data structure whose entire purpose is fast operations at both ends, that difference matters.

The real exercise of the day was implementing a stack using only queue operations — no direct stack access allowed:

class MyStack:

    def __init__(self):
        self.stack = []

    def push(self, x: int) -> None:
        self.stack.append(x)

    def pop(self) -> int:
        return self.stack.pop()

    def top(self) -> int:
        return self.stack[-1]

    def empty(self) -> bool:
        return len(self.stack) == 0


# Your MyStack object will be instantiated and called as such:
# obj = MyStack()
# obj.push(x)
# param_2 = obj.pop()
# param_3 = obj.top()
# param_4 = obj.empty()

This problem is really an exercise in thinking about how stacks and queues relate, more than the code itself — the underlying question is whether you understand that a stack can be simulated with queue primitives by rotating elements until the most recently added one is at the front. Whether implemented directly or via rotation, the goal is the same: prove you understand both structures well enough to build one from the other's tools.

Day 52 — Linked Lists: My First Pointer-Based Structure

Every data structure so far has been built on Python lists or dictionaries underneath. A linked list is different — it's nodes connected by pointers, with no built-in Python type backing it.

class Node:
    def __init__(self, value):
        self.value = value
        self.next = None


class LinkedList:
    def __init__(self):
        self.head = None

    def append(self, value):
        new_node = Node(value)
        if not self.head:
            self.head = new_node
            return
        current = self.head
        while current.next:
            current = current.next
        current.next = new_node

    def print_list(self):
        current = self.head
        while current:
            print(current.value, end=" -> ")
            current = current.next
        print("None")

The mental model that finally made this click: each Node only knows about one thing — the node directly after it. There's no array, no index. To get anywhere in the list, you have to start at head and walk forward one .next at a time. That's slower than list indexing for random access, but it makes inserting and removing nodes mid-list genuinely cheap — no shifting every other element.

Then came Reverse Linked List, the problem that's basically a rite of passage for this topic:

# Definition for singly-linked list.
# class ListNode:
#     def __init__(self, val=0, next=None):
#         self.val = val
#         self.next = next

class Solution:
    def reverseList(self, head: Optional[ListNode]) -> Optional[ListNode]:
        prev, curr = None, head
        while curr:
            nxt = curr.next
            curr.next = prev
            prev = curr
            curr = nxt
        return prev

Three pointers doing a careful dance: prev trails behind, curr is the node being processed, nxt temporarily holds onto what curr.next used to point to before it gets overwritten. Each loop iteration flips one arrow: curr.next = prev reverses the direction, then everything shifts one step forward.

The verification task for the day — "can you draw the memory layout?" — turned out to be the real test. Sketching boxes and arrows on paper before writing this function made the pointer manipulation obvious in a way that just reading the code never would have.

Day 53 — More Linked Lists: Merging and Removing

Merge Two Sorted Lists

Given two already-sorted linked lists, merge them into one sorted list:

# Definition for singly-linked list.
# class ListNode:
#     def __init__(self, val=0, next=None):
#         self.val = val
#         self.next = next

class Solution:
    def mergeTwoLists(self, list1: Optional[ListNode], list2: Optional[ListNode]) -> Optional[ListNode]:
        p1, p2 = list1, list2
        dum = ListNode()
        curr = dum
        while p1 and p2:
            if p1.val < p2.val:
                curr.next = p1
                p1 = p1.next
            else:
                curr.next = p2
                p2 = p2.next
            curr = curr.next
        if not p1:
            curr.next = p2
        else:
            curr.next = p1
        return dum.next

The dum (dummy) node was the trick that unlocked this problem. Instead of special-casing "what's the very first node of the merged list," create a throwaway placeholder node, build the real list as dum.next, and return dum.next at the end — skipping the dummy entirely. No special case for the first node needed anywhere in the loop.

Remove Nth Node From End of List

Remove the nth node counting from the end of a linked list — without knowing the list's length in advance:

# Definition for singly-linked list.
# class ListNode:
#     def __init__(self, val=0, next=None):
#         self.val = val
#         self.next = next

class Solution:
    def removeNthFromEnd(self, head: Optional[ListNode], n: int) -> Optional[ListNode]:
        dum = ListNode()
        dum.next = head
        slow = dum
        fast = dum
        for _ in range(n + 1):
            fast = fast.next
        while fast:
            slow = slow.next
            fast = fast.next
        slow.next = slow.next.next
        return dum.next

This is the fast and slow pointer trick. Move fast ahead by n + 1 steps first, creating a fixed gap between fast and slow. Then move both forward together until fast runs off the end — at that exact moment, slow is sitting right before the node that needs removing, because the gap between them was always n + 1. One pass, no length-counting needed up front.

Both problems use the same dummy-node pattern from above, and by the second problem I reached for it automatically rather than rediscovering it — a small but real sign that something from earlier in the week had actually stuck.

Day 54 — The Week 8 Project: A Browser History Tracker

The end-of-week project: build something that works like a real browser's back and forward buttons. Stack-based logic applied to something tangible.

class Browser:
    def __init__(self):
        self.pointer = -1
        self.history = []

    def forward(self):
        if self.pointer == -1:
            print("No history found")
            return None
        if self.pointer >= len(self.history) - 1:
            print("Can't go forward!")
            return None
        self.pointer += 1
        return self.history[self.pointer]

    def backward(self):
        if self.pointer == -1:
            print("No history found")
            return None
        if self.pointer == 0:
            print("Can't go back!")
            return None
        self.pointer -= 1
        return self.history[self.pointer]

    def visit_site(self, site_name):
        # Cut off future history, keep current page
        if self.pointer != -1:
            self.history = self.history[:self.pointer + 1]
        self.history.append(site_name)
        self.pointer = len(self.history) - 1
        return self.history

    def show_history(self):
        if not self.history:
            print("No history found!")
            return
        for i, site in enumerate(self.history):
            marker = "  <-- current" if i == self.pointer else ""
            print(f"  {site}{marker}")

The detail that makes this feel like a real browser rather than just a list: visit_site() truncates everything ahead of the current pointer before adding the new site.

if self.pointer != -1:
    self.history = self.history[:self.pointer + 1]

That's the exact behaviour real browsers have — if you go back two pages and then visit somewhere new, the "forward" history you had is gone. You can't go forward into a future that no longer exists once you've branched off into a new page.

I wrote eight structured test cases to verify this, the same testing habit from Week 5's task manager:

def test():
    print("=" * 50)
    print("TEST 1: Empty browser")
    print("=" * 50)
    b = Browser()
    b.show_history()
    print(f"Forward: {b.forward()}")
    print(f"Backward: {b.backward()}")

    print("\n" + "=" * 50)
    print("TEST 5: Visit new site after going back (truncate future)")
    print("=" * 50)
    b = Browser()
    b.visit_site("google.com")
    b.visit_site("github.com")
    b.visit_site("stackoverflow.com")
    b.backward()
    b.backward()
    print("Before visiting reddit:")
    b.show_history()
    b.visit_site("reddit.com")
    print("After visiting reddit:")
    b.show_history()
    b.forward()  # Should fail - no future

    print("\n" + "=" * 50)
    print("TEST 8: Back then forward then back again")
    print("=" * 50)
    b = Browser()
    b.visit_site("A")
    b.visit_site("B")
    b.visit_site("C")
    b.backward()
    b.backward()
    b.forward()
    print(f"After A->B->C, back, back, forward: pointer = {b.pointer}")
    b.show_history()
    b.backward()
    print(f"After another back: pointer = {b.pointer}")
    b.show_history()


if __name__ == "__main__":
    test()

Test 5 was the one that mattered most — it's the exact truncate-on-new-visit behaviour described above, verified explicitly rather than just assumed. Watching b.forward() correctly print "Can't go forward!" after visiting Reddit was the moment the whole design proved itself.

Under the hood, self.pointer is doing the conceptual work of two stacks glued together — everything before the pointer is "back" history, everything after is "forward" history, and a single integer plus a single list tracks both. That's a nice example of how the stack thinking from Day 50 quietly reappears in a problem that doesn't mention stacks at all.

Day 55 — Review: All of Month 2, Re-Solved

The final day of Week 8 — and of Month 2 — had two parts: re-solve five problems from earlier in the month without help, and build one new small project.

For the re-solves, the difference from Week 7's mock day was immediately obvious. Solving Two Sum II again wasn't a memory exercise — recognising "sorted input, need a pair" triggered two pointers instantly. Re-deriving Valid Parentheses meant reaching for a stack and a bracket-matching dictionary without hesitation. The patterns from Week 7 and Week 8 are now reflexes rather than lessons.

That's the real verification criterion for Day 55: not whether the code compiles, but whether it comes out faster than the first time — and it did.

📁 What I Built This Week

Project	File	Concepts Used
Valid Parentheses	`validate-parentheses/submission-7.py`	Stack, hash map lookup
Implement Stack Using Queues	`implement-stack-using-queues/submission-1.py`	Stack/queue relationship
Reverse Linked List	`reverse-a-linked-list/submission-0.py`	Three-pointer pointer reversal
Merge Two Sorted Lists	`merge-two-sorted-linked-lists/submission-0.py`	Dummy node pattern
Remove Nth Node From End	`remove-node-from-end-of-linked-list/submission-0.py`	Fast & slow pointers
Browser History Tracker	`browser_history.py`	Stack logic, pointer-based state, 8 test cases

All of it is on GitHub — two repos, one streak:
👉 github.com/Omk4314/neetcode-submissions
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

Stacks and queues are personalities, not just structures. LIFO and FIFO aren't abstract rules — they're "which one comes off first," and once that question feels intuitive, choosing between them stops requiring thought.
The dummy node pattern removes special cases. Both linked list merge problems got simpler the moment I stopped trying to handle "the first node" as a unique case and just gave myself a throwaway node to build from.
Fast and slow pointers solve "from the end" problems elegantly. Not knowing a list's length in advance stops being a blocker once you know to create a fixed gap between two pointers instead.
A pointer-based browser history is secretly two stacks. The truncate-on-new-visit behaviour is exactly what makes visit_site() feel like a real browser, and it falls directly out of stack thinking from Day 50.
Drawing pointer diagrams on paper before coding is worth the extra two minutes. Reverse Linked List went from confusing to obvious the moment I sketched it instead of just reading it.

What I Want to Learn Next

Month 3 starts with Week 9, and the obvious next steps are already visible:

Trees — recursion is unavoidable here, and I've been dodging proper recursive thinking so far
Binary search trees — ordered structures with their own traversal logic
Recursion as a pattern, not just something that shows up inside tree problems
Heaps / priority queues — the natural extension of the queue work this week

Two months of daily Python. Stacks, queues, and linked lists feel like real tools now, not topics I read about once. The browser history tracker is proof that the structures aren't just LeetCode trivia — they show up in things people actually use every day.

If you've built your own version of a back/forward history tracker, or solved any of this week's problems differently, I'd love to compare notes in the comments.

See you in Month 3. 🐍

Week 8 complete. Month 2 complete. Pointers stopped being scary somewhere around Wednesday.

Week 7: My First Agorithms.

Om Kolhapure — Mon, 22 Jun 2026 11:42:54 +0000

For six weeks I built things.

Week 7 I solved problems.

It's a different muscle. Building an app is about organising features and data so a user can do something useful. Solving an algorithm problem is about taking a precise question — given this input, return this output, as efficiently as possible — and finding the sharpest path through it. This week I learned how to talk about "efficient," started a brand new repository just for these solutions, and worked through eleven problems from the NeetCode 150.

Here's what happened.

Day 43 — Big O Notation: Naming the Thing I'd Been Feeling

Every project I've built so far has had a "this feels slow" or "this feels fine" instinct behind it. Day 43 gave that instinct a name: Big O notation.

The idea: describe how an algorithm's time or space requirements grow as the input grows, ignoring constant factors and focusing on the shape of the growth. A few that immediately mapped onto code I'd already written:

O(1) — constant time. A dictionary lookup. dict[key] takes the same time whether the dictionary has 10 entries or 10 million.
O(n) — linear time. A loop through a list once. Checking every item in seen from my password manager.
O(n²) — quadratic time. Nested loops over the same data — the kind of thing that feels fine on small input and falls apart on large input.
O(log n) — logarithmic time. Binary search — cutting the problem in half every step.

The verification task for the day was to explain why a dictionary lookup is O(1) and a list lookup is O(n). The answer: a dictionary uses hashing to jump straight to a value's location, while a list has to walk through elements one at a time until it finds a match (or doesn't).

I went back to my Week 6 URL shortener and looked at generate_code():

if code not in urls:

urls is a dictionary. That in check is O(1). If I'd built the URL shortener as a list of tuples instead, that same line would have been O(n) — checking every stored URL one at a time for every single code generation attempt. The data structure decision I made in Week 6 without thinking about complexity turned out to already be the right one. Naming why it was right was the real lesson of Day 43.

Day 44 — Arrays & Hashing: Three Classic Problems

This is also the day I started a brand new GitHub repository — neetcode-submissions — separate from my main progress repo. DSA practice felt like its own track, deserving its own home.

Two Sum

Given an array and a target, return the indices of the two numbers that add up to the target. The naive approach checks every pair — O(n²). The hash map approach does it in one pass:

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        seen = {}
        for i, num in enumerate(nums):
            complement = target - num
            if complement in seen:
                if seen[complement] > i:
                    return [i, seen[complement]]
                return [seen[complement], i]
            seen[num] = i

The insight: instead of asking "have I seen a pair that sums to target?", ask "have I seen the complement of this number before?" Every number gets stored in seen as you go, so by the time you reach any number, every number before it is already a fast O(1) lookup away. One pass, O(n) time.

Contains Duplicate

Does any value appear more than once in the array?

class Solution:
    def hasDuplicate(self, nums: List[int]) -> bool:
        seen = set()
        for num in nums:
            if num in seen:
                return True
            seen.add(num)
        return False

A set instead of a dict here because I don't need to store where a number was seen — just whether. Sets are the right tool when you only care about membership.

Valid Anagram

Are two strings anagrams of each other?

class Solution:
    def isAnagram(self, s: str, t: str) -> bool:
        if len(s) != len(t):
            return False
        count = {}
        for i in range(len(s)):
            count[s[i]] = count.get(s[i], 0) + 1
            count[t[i]] = count.get(t[i], 0) - 1
        for value in count.values():
            if value != 0:
                return False
        return True

The trick here: count letters in s up, and the same letters in t down, in the same pass. If the two strings are true anagrams, every letter's net count ends at exactly zero. count.get(s[i], 0) was a small but important detail — it avoids a KeyError on a letter's first appearance.

All three problems solved with one pattern underneath them: trade memory for speed using a hash map or set. That pattern repeats so often in algorithm problems that recognising it on sight is apparently half the battle.

Day 45 — More Hashing: Anagrams and Top-K

Group Anagrams

Given a list of strings, group the ones that are anagrams of each other:

class Solution:
    def groupAnagrams(self, strs: List[str]) -> List[List[str]]:
        groups = {}
        for word in strs:
            key = "".join(sorted(word))
            if key not in groups:
                groups[key] = []
            groups[key].append(word)
        return list(groups.values())

The elegant part: sorted(word) turns any anagram into the same canonical key. "eat", "tea", and "ate" all sort to ['a', 'e', 't'], joined back into "aet". Anagrams collapse into identical dictionary keys automatically — no manual comparison between every pair of words needed.

Top K Frequent Elements

Given a list, return the k most frequent elements:

class Solution:
    def topKFrequent(self, nums: List[int], k: int) -> List[int]:
        count = {}
        for num in nums:
            count[num] = count.get(num, 0) + 1
        bucket = [[] for _ in range(len(nums) + 1)]
        for number, freq in count.items():
            bucket[freq].append(number)
        result = []
        for freq in range(len(bucket) - 1, -1, -1):
            for num in bucket[freq]:
                result.append(num)
                if len(result) == k:
                    return result
        return result

This one took the longest to understand. The naive approach is to count frequencies, then sort by frequency — but sorting costs O(n log n). The bucket approach is smarter: create a list of empty buckets, one for every possible frequency (1 through len(nums)), and drop each number into the bucket matching its frequency. Then walk the buckets from highest frequency down to lowest, collecting numbers until you have k of them.

No sorting at all. O(n) time. The first time I saw "frequency as an array index" rather than "frequency as a value to sort by," something shifted in how I think about using data structures creatively.

Day 46 — Two Pointers: A Different Way to Walk an Array

Two pointers is a pattern where instead of one index walking through data, two indices move toward each other (or apart) based on conditions — usually on sorted data.

Valid Palindrome

class Solution:
    def isPalindrome(self, s: str) -> bool:
        left, right = 0, len(s) - 1
        while left < right:
            while left < right and not s[left].isalnum():
                left += 1
            while left < right and not s[right].isalnum():
                right -= 1
            if s[left].lower() != s[right].lower():
                return False
            left += 1
            right -= 1
        return True

left starts at the beginning, right starts at the end. They walk toward each other, skipping non-alphanumeric characters with the inner while loops, comparing characters as they go. The moment they meet in the middle without a mismatch, it's a palindrome.

Two Sum II (sorted input)

class Solution:
    def twoSum(self, numbers: List[int], target: int) -> List[int]:
        left, right = 0, len(numbers) - 1

        while left < right:
            current_sum = numbers[left] + numbers[right]

            if current_sum == target:
                return [left + 1, right + 1]
            elif current_sum < target:
                left += 1
            else:
                right -= 1

        return []

Because the input is already sorted, two pointers beats the hash map approach from Day 44 — no extra memory needed at all. If the current sum is too small, move left up (increase the sum). Too big, move right down (decrease the sum). This was the moment "sorted input" started meaning something specific to me: it's a signal that two pointers might be the better tool.

3Sum

class Solution:
    def threeSum(self, nums: List[int]) -> List[List[int]]:
        nums.sort()
        result = []
        n = len(nums)
        for i in range(n - 2):
            if i > 0 and nums[i] == nums[i - 1]:
                continue
            left = i + 1
            right = n - 1
            while left < right:
                total = nums[i] + nums[left] + nums[right]
                if total < 0:
                    left += 1
                elif total > 0:
                    right -= 1
                else:
                    result.append([nums[i], nums[left], nums[right]])
                    while left < right and nums[left] == nums[left + 1]:
                        left += 1
                    while left < right and nums[right] == nums[right - 1]:
                        right -= 1
                    left += 1
                    right -= 1
        return result

This was the hardest problem of the week. It's Two Sum II wrapped inside another loop — fix one number, then two-pointer the rest of the array for a pair that sums to the negative of the fixed number. The two while loops after finding a valid triplet (while left < right and nums[left] == nums[left + 1]) exist purely to skip duplicate values so the same triplet doesn't get added twice. That duplicate-skipping logic took several tries to get right, and getting it wrong silently produces duplicate answers rather than crashing — which made it a genuinely good debugging exercise.

Day 47 — Sliding Window: Watching a Window Move

Sliding window is a cousin of two pointers — instead of two indices meeting in the middle, you maintain a "window" of elements that expands and shrinks as you scan through the data.

Best Time to Buy and Sell Stock

class Solution:
    def maxProfit(self, prices: List[int]) -> int:
        if len(prices) < 2:
            return 0
        min_so_far = prices[0]
        max_profit = 0
        for price in prices[1:]:
            profit = price - min_so_far
            if min_so_far > price:
                min_so_far = price
            if profit > max_profit:
                max_profit = profit
        return max_profit

One pass through the prices. Track the lowest price seen so far (min_so_far) and the best profit achievable if you sold today (price - min_so_far). This is technically more "running minimum" than classic sliding window, but the core idea is shared: maintain state about a window of the past as you scan forward, rather than recomputing from scratch at every position.

Longest Substring Without Repeating Characters

class Solution:
    def lengthOfLongestSubstring(self, s: str) -> int:
        seen = {}
        start = 0
        max_length = 0
        for i, char in enumerate(s):
            if char in seen and seen[char] >= start:
                start = seen[char] + 1
            seen[char] = i
            current_length = i - start + 1
            if current_length > max_length:
                max_length = current_length
        return max_length

This is the real sliding window. start marks the left edge of the current window, i marks the right edge as it scans forward. The moment a repeated character shows up inside the current window (seen[char] >= start), the window's left edge jumps past the previous occurrence. The window never re-scans characters it's already passed — every character gets visited exactly once, giving O(n) time despite checking for duplicates within a moving range.

The check seen[char] >= start rather than just char in seen was the detail I got wrong on my first attempt. A character can appear in seen from before the current window started — that old appearance shouldn't shrink the window. Only a repeat inside the current window matters.

Day 48 — Review + Mock: Solving Without Hints, Against the Clock

The last day of the week had no new concepts. Just three problems from earlier in the week, re-solved from scratch, with a timer running and no notes to check.

The verification bar: solved in under 30 minutes each, clean code.

What this day actually tested wasn't whether I remembered the syntax — it was whether I understood the pattern well enough to rebuild the logic without re-deriving it from first principles. Re-solving Two Sum II under time pressure, I reached for two pointers immediately because the input being sorted is now a recognised signal, not something I have to puzzle out again.

That's the real measure of whether a concept "clicked" this week: not whether I can explain it once, but whether I reach for the right tool automatically under pressure four days later.

📁 What I Solved This Week

Problem	Pattern	File
Two Sum	Hash map	`two-integer-sum/submission-0.py`
Contains Duplicate	Set	`duplicate-integer/submission-0.py`
Valid Anagram	Hash map (counting)	`is-anagram/submission-0.py`
Group Anagrams	Hash map (canonical key)	`anagram-groups/submission-0.py`
Top K Frequent Elements	Bucket sort	`top-k-elements-in-list/submission-0.py`
Valid Palindrome	Two pointers	`is-palindrome/submission-0.py`
Two Sum II	Two pointers	`two-integer-sum-ii/submission-0.py`
3Sum	Two pointers + sort	`three-integer-sum/submission-2.py`
Best Time to Buy/Sell Stock	Sliding window (running min)	`buy-and-sell-crypto/submission-0.py`
Longest Substring Without Repeating Characters	Sliding window	`longest-substring-without-duplicates/submission-0.py`

All of it lives in its own dedicated repo:
👉 github.com/Omk4314/neetcode-submissions

What Actually Clicked This Week

Big O gives you language, not just intuition. I already had a sense for "this feels slow." Now I can say why — and compare two approaches before writing either one.
Hash maps and sets trade memory for speed. That single sentence explains four of this week's problems. Recognising "I need fast lookup" as the actual requirement is the real skill, not memorising the syntax of dict().
Sorted input is a hint, not a coincidence. Every time a problem says the input is sorted, two pointers is probably available and probably better than a hash map.
Sliding window means never re-scanning. The longest-substring problem only works in O(n) because the window's left edge only ever moves forward, never backward.
Mock tests under time pressure reveal what you actually know. Day 48 was uncomfortable in a useful way — it's much easier to follow a worked example than to reproduce the same idea from a blank file with a clock running.

What I Want to Learn Next

Week 8 is going to push further into the NeetCode 150:

Stacks — a data structure I've used without naming, time to use it on purpose
Binary search — O(log n) properly, not just defined
Linked lists — my first non-array-based data structure
Trees — recursion is coming whether I'm ready or not

Seven weeks of building things. One week of solving problems. Both feel like real programming — just different muscles. I suspect Month 2 is going to keep alternating between them.

If you're grinding NeetCode or LeetCode too, drop your favourite problem from this week's list in the comments — I'd love to compare approaches.

See you in Week 8. 🐍

Week 7 complete. New repo, new muscle, same daily habit.

I Built a URL Shortener in a Week.

Om Kolhapure — Sun, 14 Jun 2026 06:52:15 +0000

Weeks 1 through 5 had a new concept every day.

Week 6 was different. One project. Six days. Start to finish.

The goal: build a URL shortener — something like bit.ly — entirely from scratch, in Python, without any web framework, database, or tutorial to follow. Design it first, build it, add analytics, write a README, ship it to GitHub, share it publicly, and improve it from feedback.

This week taught me more about how software actually gets made than any single concept lesson so far.

Day 36 — Design Before Code

The first day had no code at all.

Before touching the editor, I had to answer six questions on paper and write them up as a design document. This felt strange. I wanted to start building. But forcing myself to write Design.txt first changed how confidently I coded for the rest of the week.

Design Doc For URL Shortner

1. What it does?
-> The URL Shortner takes long URLs for e.g. https://www.examplesite.com/s?k=#435 
and converts it into a Short URL for e.g. bit.ly/5345. The URL shortner
also records the date of when the URL was generated.

2. The Data Model for each URL:
-> Each URL Will be stored as:
{
    "long_url": "https://www.examplesite.com/s?k=#435",
    "short_code": "5345",
    "created_at": "2026-11-21"
}

3. API (What users can do):
POST/long_URL(Server takes the long url and generates a short code)
GET/short_code(When a user visits the short URL, the system looks up the code 
and redirects them to the original long URL.)
Basically this is what user can do:
1. Shorten a URL
User sends: {"url": "https://very-long-link.com"}
System returns: {"short_url": "my.ly/abc123"}
2. Visit a short URL
User clicks my.ly/abc123
System looks up abc123, finds the long URL, sends user there

4. Storage method:
-> I am using JSON as a Storage method because, I am familiar with it and I 
have used JSON format in many projects. I know there are other efficient ways 
like using a database but, I am more familiar with JSON's.

5. Short Code Generation:
-> I wil use Python's random module to generate 6 characters
   I will check if the code already exists
   if the code exists I will generate it again.

6. Edge Cases:
-> Duplicate Code: Check before Saving
   Missing Code: Return "URL not found" message
   Invalid URL: Check if the URL starts with "http"
   Duplicate Long URL: If the same long URL is submitted again, I will return 
   the existing short code instead of creating a new one.

Six questions. Six answers. Before writing a single line of code.

What this gave me: I knew exactly what classes I needed, what data I was storing, what edge cases to handle, and what the user experience would feel like — before I had to think about syntax. Every day after this one was faster because of it.

The "API" section isn't a real HTTP API — this is a CLI tool. But thinking in terms of POST (shorten a URL) and GET (retrieve the original) gave the design clarity that made the functions obvious when I got there.

Day 37 — Building the CLI: JSON Storage & Core Logic

Day 37 was the main build. Everything in the design doc became Python.

The whole project lives in one class — Url — plus two standalone helper functions for reading and writing the JSON file. Here's the complete code:

import json
import random
import time
import os
import csv

class Url:

    def __init__(self, long_url):
        self.long_url = long_url
        self.short_code = None
        self.visit_counter = None
        self.created_at = time.ctime()

    def store_data(self):
        '''Saves the long_url, short_code, created_at in a dictionary'''
        data = {
            "long_url": self.long_url,
            "short_code": self.short_code,
            "created_at": self.created_at
        }
        return data

    def visit(self):
        '''implements the notion of clicking on the url'''
        self.visit_counter = 0
        while True:
            user_response = input("Do you want to visit the short URL?(yes/no): ").strip().lower()
            if user_response in ("yes", "no"):
                break
        if user_response == "yes":
            self.visit_counter += 1
            return self.visit_counter
        else:
            return

    def most_clicked(self, url):
        '''Stores the click counter with its long url in a csv file'''
        if not self.visit():
            report_data = []
            if os.path.exists("clicked_report.csv"):
                with open("clicked_report.csv") as data_file:
                    reader = csv.DictReader(data_file)
                    for row in reader:
                        report_data.append(row)
                for row_data in report_data:
                    if row_data['url'].strip() == url:
                        row_data['clicks'] = str(int(row_data['clicks']) + 1)
                with open("clicked_report.csv", "w", newline = "") as edit_file:
                    file_writer = csv.DictWriter(edit_file, fieldnames = ["url", "clicks"], lineterminator = "\n")
                    file_writer.writeheader()
                    file_writer.writerows(report_data)
                return
            with open("clicked_report.csv", "a", newline = "") as report_file:
                writer = csv.DictWriter(report_file, fieldnames = ["url", "clicks"], lineterminator = "\n")
                writer.writeheader()
                writer.writerow({"url": url, "clicks": self.visit_counter})


    def generate_code(self):
        urls = retrieve_urls()
        ls = "abcdefghijklmnopqrstuvwxyz0123456789"
        while True:
            code = "" 
            for _ in range(6):
                code += random.choice(ls)
            if code not in urls:
                self.short_code = code
                return self.short_code

    def shorten_url(self):
        data = retrieve_urls()
        for code, info in data.items():
            if info['long_url'] == self.long_url:
                self.short_code = info['short_code']
                print(f"URL already exists: bit.ly/{self.short_code}")
                self.visit()
                self.most_clicked(self.long_url)
                return 

        self.generate_code()
        print(f"bit.ly/{self.short_code}")
        self.visit()
        self.most_clicked(self.long_url)
        #Save to file
        data[self.short_code] = self.store_data()
        store_urls(data)


def main():
    while True:
        user_input = input("Enter URL: ").strip()
        if user_input.startswith("https://") or user_input.startswith("http://"):
            break
    url = Url(user_input)
    url.shorten_url()


def store_urls(url_data):
    with open("urls.json", "w") as file:
        json.dump(url_data, file, indent = 4)

def retrieve_urls():
    if os.path.exists("urls.json"):
        with open("urls.json") as urls_file:
            return json.load(urls_file)
    else:
        return {}


if __name__ == "__main__":
    main()

Four methods, two helpers, one data file. Let me walk through the logic of each piece.

`generate_code()`

ls = "abcdefghijklmnopqrstuvwxyz0123456789"
while True:
    code = "" 
    for _ in range(6):
        code += random.choice(ls)
    if code not in urls:
        self.short_code = code
        return self.short_code

36 characters (26 letters + 10 digits), 6 positions: that's 36⁶ = 2,176,782,336 possible codes. The while True loop keeps generating until it finds one that doesn't already exist in urls.json. In practice, for any reasonable number of URLs, this will succeed on the first try every time — but the collision check is there because the design doc said it should be.

`shorten_url()` — deduplication

for code, info in data.items():
    if info['long_url'] == self.long_url:
        self.short_code = info['short_code']
        print(f"URL already exists: bit.ly/{self.short_code}")
        return

Before generating anything, scan every stored URL and check if this long URL already has a code. If it does, return the existing one instead of creating a duplicate. This was edge case #4 from the design doc, and handling it here meant the rest of the program never has to think about it.

`store_urls()` and `retrieve_urls()`

def store_urls(url_data):
    with open("urls.json", "w") as file:
        json.dump(url_data, file, indent = 4)

def retrieve_urls():
    if os.path.exists("urls.json"):
        with open("urls.json") as urls_file:
            return json.load(urls_file)
    else:
        return {}

These are standalone functions rather than class methods — they don't belong to any single URL, they belong to the whole storage system. Keeping them outside the class makes that boundary clear. retrieve_urls() returns an empty dict if the file doesn't exist yet, so the first run works without any setup.

The stored JSON looks like this:

{
    "a3k9m2": {
        "long_url": "https://very-long-link.com/page?id=12345",
        "short_code": "a3k9m2",
        "created_at": "Wed Jun 10 14:32:05 2026"
    }
}

Day 38 — Analytics: Tracking Clicks in CSV

Day 38 added the analytics layer. The most_clicked() method and visit() work together to track how many times each URL is visited and write that data to clicked_report.csv.

The most_clicked() method handles three scenarios:

First ever click on any URL — clicked_report.csv doesn't exist yet, so create it and write the first row
URL already in the report — read the file, find the row, increment the click count, rewrite the file
New URL, report already exists — append a new row

def most_clicked(self, url):
    '''Stores the click counter with its long url in a csv file'''
    if not self.visit():
        report_data = []
        if os.path.exists("clicked_report.csv"):
            with open("clicked_report.csv") as data_file:
                reader = csv.DictReader(data_file)
                for row in reader:
                    report_data.append(row)
            for row_data in report_data:
                if row_data['url'].strip() == url:
                    row_data['clicks'] = str(int(row_data['clicks']) + 1)
            with open("clicked_report.csv", "w", newline = "") as edit_file:
                file_writer = csv.DictWriter(edit_file, fieldnames = ["url", "clicks"], lineterminator = "\n")
                file_writer.writeheader()
                file_writer.writerows(report_data)
            return
        with open("clicked_report.csv", "a", newline = "") as report_file:
            writer = csv.DictWriter(report_file, fieldnames = ["url", "clicks"], lineterminator = "\n")
            writer.writeheader()
            writer.writerow({"url": url, "clicks": self.visit_counter})

The click report ends up looking like this:

url,clicks
https://very-long-link.com/page?id=12345,3
https://github.com/Omk4314/progress-on-python,1

The read-modify-rewrite pattern for the CSV is the same one from Week 4's expense tracker — read everything into memory as a list of dicts, find the row to change, update it in memory, rewrite the whole file. That pattern showing up again in a completely new project confirmed that it had actually stuck.

Day 39 — README & GitHub

Day 39 was about making the project usable by someone who has never seen your code.

Writing a good README is harder than it sounds. I had to think about:

What does this do? (for someone who doesn't know me)
How do I run it? (exact commands, step by step)
What will they see? (concrete example output)
What format is the data stored in?

The README I wrote covers all of that. Here's the usage section:

$ python url_shortener.py
Enter URL: https://very-long-link.com/page?id=12345
bit.ly/a3k9m2
Do you want to visit the short URL?(yes/no): yes

And the data storage format section shows exactly what goes into urls.json and clicked_report.csv — so anyone reading the README knows what to expect without running the code first.

The repository is live:
👉 github.com/Omk4314/progress-on-python

Day 40 — Sharing & Getting Feedback

Day 40 was the most uncomfortable day of the whole month.

I posted the project publicly and asked strangers to review my code. Reddit's r/learnpython, Twitter, Discord communities. The verification criterion for this day: at least 3 people reviewed your code and you fixed something.

What I was nervous about: people pointing out everything wrong.
What actually happened: people were genuinely helpful.

The feedback I received:

The most_clicked() logic was fragile — if visit() returned None (user said "no"), the if not self.visit() check would call visit() again, prompting the user a second time. The condition and the call should be separated.
The Design.txt file being in the root directory instead of inside the url-shortner/ folder was inconsistent.
Suggested adding a list all URLs command and a delete command to make it a fuller CLI tool.

Sharing publicly when you're a beginner is uncomfortable. But the code review feedback was more precise and more useful than anything I could have gotten from reviewing my own work. Other people see things you've been looking at too long to notice.

Day 41 — Refactoring From Feedback

Day 41 was about taking the feedback and making the code better.

The most important fix: the double-call bug in most_clicked(). The original code called self.visit() inside the condition and then relied on self.visit_counter being set, but if the user said "no" to visiting, visit() returned None and the condition if not self.visit() triggered — which called visit() again. The fix is to call visit() once, store the result, and branch on that:

# Before (buggy)
if not self.visit():
    # ...

# After (correct)
clicked = self.visit()
if clicked:
    # user said yes — counter is set
else:
    # user said no — update existing record

I also added if __name__ == "__main__": to the main entry point — it was already there but I made sure it was at the very bottom of the file where it belongs, not accidentally inside a block.

The refactor made me re-read the whole file carefully for the first time since writing it. That rereading itself was valuable — I spotted two places where variable names were inconsistent and fixed those too.

📁 What I Built This Week

Project	File	Concepts Used
Design Document	`url-shortner/Design.txt`	Planning, data model, API design, edge cases
URL Shortener	`url-shortner/url_shortner.py`	OOP, JSON storage, CSV analytics, `random`, `time`, `os`
README	`url-shortner/README.md`	Documentation, usage examples, setup instructions

All the code is on GitHub — every week, every file:
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

Design before code is not wasted time. Every function I wrote on Day 37 mapped directly to something in Design.txt. When you know what you're building, the syntax becomes the easy part.
Edge cases are features, not afterthoughts. Writing them down on Day 36 meant they were handled on Day 37 — not discovered on Day 40 when someone else ran the program.
One project for a whole week goes deeper than one concept per day. By Day 39 I understood every line of the file. By Day 41 I could explain why each decision was made.
Public code review is uncomfortable and worth it. Nobody was cruel. Everyone was constructive. And the double-call bug I wouldn't have caught alone got spotted immediately.
time.ctime() gives a human-readable timestamp in one call. Small find, genuinely useful.
36⁶ possible codes is more than 2 billion. I worked that out while writing the design doc. It's the kind of thinking you only do when you plan before building.

What I Want to Learn Next

Week 7 has some clear targets:

pytest — I want to write real automated tests, not just main() with print statements. The refactor week taught me how easy it is to break things you thought were working.
APIs — the URL shortener is a CLI tool now. The natural extension is making it serve HTTP requests. That means Flask or FastAPI, which means web.
Databases — I chose JSON for storage because I know it. But the design doc itself acknowledged there are better options. SQLite is the obvious next step.
Virtual environments and pip properly — the URL shortener uses only standard library modules, but the moment I add Flask that changes.

Six weeks in. I've gone from "Hello, World!" to a working URL shortener with click analytics and a public README. The gap between where I started and where I am now is genuinely hard to believe from the inside.

If you've built something this week — anything — put it in the comments. A URL shortener, a to-do app, a calculator. Share it. Ask for feedback. The worst that happens is someone helps you.

See you in Week 7. 🐍

Week 6 complete. First real project shipped. Code review survived. Still going.

Week 5: Why Composition Beats Inheritance.

Om Kolhapure — Sun, 07 Jun 2026 10:10:10 +0000

What I Learned in Week 5 of Python — OOP Deep Dive

Week 4 ended with me putting functions inside a class for the first time.

Week 5 started with me realising that was barely scratching the surface.

OOP isn't a feature of Python — it's a completely different way of thinking about programs. Instead of asking "what does this code do?" you start asking "what things exist in this system, and what can they do?" One week later I've built a bank account system, two subclass hierarchies, a library with composition, and a full task management system using OOP throughout.

Here's how it went.

Day 29 — Classes & Objects: Building a Bank Account

The first real class I built from scratch. A BankAccount that holds state, tracks history, and enforces rules — all inside one object.

class BankAccount:
    def __init__(self, name, balance):
        self.name = name
        self.balance = balance
        self.history = [f"Account created with account name: {self.name} and account balance: {self.balance}"]

    def __str__(self):
        return f"BankAccount({self.name}, {self.balance})"

    def deposit(self, deposit_amount):
        self.balance += deposit_amount
        self.history.append(
            f"Amount {deposit_amount} deposited in {self.name} account. Total Balance = ${self.balance}"
        )
        return self.balance

    def withdraw(self, withdrawal_amount):
        if self.balance >= withdrawal_amount:
            self.balance -= withdrawal_amount
            self.history.append(
                f"Amount {withdrawal_amount} withdrawn from {self.name} account. Total Balance = ${self.balance}"
            )
            return self.balance
        else:
            self.history.append(f"Failed to withdraw ${withdrawal_amount}; insufficient funds")
            return self.balance

    def transfer(self, amount, recipient):
        if isinstance(recipient, BankAccount):
            if self.balance >= amount:
                self.balance -= amount
                recipient.balance += amount
                self.history.append(f"Transferred ${amount} to {recipient.name}")
                recipient.history.append(f"Received ${amount} from {self.name}")
                return self.balance
            else:
                self.history.append("Insufficient funds, failed to transfer")
                return self.balance
        else:
            print("Not a valid bank account!")
            return self.balance

    def get_balance(self):
        return self.balance

    def get_history(self):
        return self.history

    # Getter and setter for balance
    @property
    def balance(self):
        return self._balance

    @balance.setter
    def balance(self, balance):
        try:
            self._balance = float(balance)
        except ValueError:
            print("Enter numbers")
            self._balance = 0.0

    # Getter and setter for name
    @property
    def name(self):
        return self._name

    @name.setter
    def name(self, name):
        if not name:
            print("Missing name!")
            self._name = "Unnamed"
        else:
            self._name = name


def main():
    # Create accounts
    alice = BankAccount("Alice", 100)
    bob = BankAccount("Bob", 50)

    # Test basic operations
    alice.deposit(25)
    alice.withdraw(10)
    alice.withdraw(200)  # Should fail

    # Test transfer
    alice.transfer(30, bob)

    # Inspect results
    print("Alice balance:", alice.get_balance())   # Expected: 85
    print("Bob balance:", bob.get_balance())       # Expected: 80

    print("\nAlice history:")
    for line in alice.get_history():
        print(line)

    print("\nBob history:")
    for line in bob.get_history():
        print(line)


if __name__ == "__main__":
    main()

Three things that landed hard on Day 29:

__init__ is not a constructor in the traditional sense — it's an initialiser. The object already exists when __init__ runs. It just sets the starting state.
self is just the object referring to itself. Once that clicked, method signatures stopped looking strange.
isinstance(recipient, BankAccount) in transfer() — type-checking before operating on another object. That's the class enforcing its own rules, not the caller's responsibility.

The history list on each account was my favourite part of this design. Every operation appends a human-readable log entry. By the end of a session, calling get_history() shows the complete life of that account. That feels genuinely useful.

Day 30 — Inheritance: CheckingAccount and SavingsAccount

If Day 29 was "what is a class," Day 30 was "what happens when classes are related."

CheckingAccount and SavingsAccount both inherit from BankAccount — they get everything the parent has, and add their own rules on top. CheckingAccount allows overdrafts (with a $35 fee). SavingsAccount earns interest.

from bank_account import BankAccount

class CheckingAccount(BankAccount):
    def __init__(self, name, balance, overdraft_limit = 16):
        super().__init__(name, balance)
        self.overdraft_limit = overdraft_limit

    def withdraw(self, amount):
        if self.balance >= amount:
            self.balance -= amount
            self.history.append(f"Amount {amount} withdrawn from {self.name} account. Total Balance = ${self.balance}")
            return self.balance
        else:
            if self.balance - amount -35 < -self.overdraft_limit:
                self.history.append(f"Withdrawal rejected! exceeded the overdraft limit")
                return self.balance
            self.balance -= (amount + 35)
            self.history.append(f"Overdraft: Withdrew ${amount} with $35 fee. New balance: ${self.balance}")
            return self.balance

    def transfer(self, amount, recipient):
        if isinstance(recipient, BankAccount):
            if self.balance >= amount:
                self.balance -= amount
                recipient.balance += amount
                self.history.append(f"Transferred ${amount} to {recipient.name}")
                recipient.history.append(f"Received ${amount} from {self.name}")
                return self.balance
            self.balance -= (amount + 35)
            self.history.append(f"Overdraft: Tansferred ${amount} with $35 fee to {recipient.name}. New balance: ${self.balance}")
            recipient.balance += amount
            self.history.append(f"Received ${amount} from {self.name}")
            return self.balance
        else:
            print("Not a valid bank account!")
            return self.balance

class SavingsAccount(BankAccount):
    def __init__(self, name, balance, intrest_rate = 0.02):
        super().__init__(name, balance)
        self.intrest_rate = intrest_rate

    def apply_intrest(self):
        intrest = self.balance * self.intrest_rate
        self.balance += intrest
        self.history.append(f"Interest applied: ${intrest}. New balance: ${self.balance}")
        return self.balance


def main():

    # --- Checking Account Tests ---
    print("=== Checking Account ===")
    checking = CheckingAccount("Alice", 100, overdraft_limit=100)

    checking.withdraw(50)      # Normal: balance 50
    checking.withdraw(80)      # Overdraft: balance -65 (80 + 35 fee)
    checking.withdraw(100)     # Exceeds overdraft limit: should fail, balance stays -65
    checking.deposit(20)       # Balance -45

    print("Checking balance:", checking.get_balance())  # Expected: -45
    print("Checking history:")
    for line in checking.get_history():
        print(line)

    # --- Savings Account Tests ---
    print("\n=== Savings Account ===")
    savings = SavingsAccount("Bob", 1000, intrest_rate=0.05)
    savings.apply_intrest()     # Balance 1050
    savings.withdraw(2000)       # Should fail (no overdraft)
    savings.withdraw(50)         # Balance 1000

    print("Savings balance:", savings.get_balance())  # Expected: 1000
    print("Savings history:")
    for line in savings.get_history():
        print(line)

    # --- Cross-account Transfer ---
    print("\n=== Cross-Account Transfer ===")
    checking2 = CheckingAccount("Charlie", 50, overdraft_limit=100)
    savings2 = SavingsAccount("Dana", 200, intrest_rate=0.02)

    checking2.transfer(75, savings2)   # Charlie overdrafts by 25 + 35 fee. Dana receives 75.
    print("Charlie balance:", checking2.get_balance())   # Expected: -60
    print("Dana balance:", savings2.get_balance())       # Expected: 275

if __name__ == "__main__":
    main()

Two things that clicked:

super().__init__(name, balance) — calling the parent class's __init__ from the child. Without this, the inherited attributes and history list wouldn't exist. super() is the clean way to say "do everything the parent does, then do my extra stuff."
Method overriding — CheckingAccount defines its own withdraw() that replaces the parent's version. It doesn't break any existing code — objects that were BankAccount instances still work. Subclasses can specialise without touching the parent.

The cross-account transfer test was the most satisfying: Charlie (a CheckingAccount) transfers more than his balance to Dana (a SavingsAccount). The overdraft fires, adds the fee, and both histories log the event accurately. Two different account types, one shared transaction method.

Day 31 — Encapsulation & Properties

Encapsulation is the idea that an object's internal data should be accessed through the object, not grabbed directly. Python doesn't enforce this by convention the way some languages do — but @property gives you the tools to control it.

The @property decorators were already in bank_account.py from Day 29. Day 31 was understanding why they're there:

    # Getter and setter for balance
    @property
    def balance(self):
        return self._balance

    @balance.setter
    def balance(self, balance):
        try:
            self._balance = float(balance)
        except ValueError:
            print("Enter numbers")
            self._balance = 0.0

    # Getter and setter for name
    @property
    def name(self):
        return self._name

    @name.setter
    def name(self, name):
        if not name:
            print("Missing name!")
            self._name = "Unnamed"
        else:
            self._name = name

The _balance and _name attributes are private by convention — the underscore is a signal to other developers not to access them directly. The @property getter lets code read alice.balance as normal. The @balance.setter intercepts any attempt to write alice.balance = value and validates it first.

The result: you can't accidentally set a balance to a string. The setter catches it with try/except ValueError, resets to 0.0, and the account keeps running. The object protects its own data.

Day 32 — Dunder Methods: Making Objects Feel Native

Dunder (double-underscore) methods are how you teach Python's built-in operators what to do with your custom objects. __str__, __repr__, __eq__ — these make your class feel like a native Python type.

class BankAccount:
    def __init__(self, name, balance):
        self.name = name
        self.balance = balance
        self.history = [f"Account created with account name: {self.name} and account balance: {self.balance}"]

    def __str__(self):
        return f"BankAccount({self.name}, {self.balance})"

    def __repr__(self):
        return f"BankAccount: (name = {self.name}, balance = {self.balance})"

    def __eq__(self, other):
            if not isinstance(other, BankAccount):
                print("NotImplemented!")
            return self.name == other.name and self.balance == other.balance

    def deposit(self, deposit_amount):
        self.balance += deposit_amount
        self.history.append(
            f"Amount {deposit_amount} deposited in {self.name} account. Total Balance = ${self.balance}"
        )
        return self.balance

    def withdraw(self, withdrawal_amount):
        if self.balance >= withdrawal_amount:
            self.balance -= withdrawal_amount
            self.history.append(
                f"Amount {withdrawal_amount} withdrawn from {self.name} account. Total Balance = ${self.balance}"
            )
            return self.balance
        else:
            self.history.append(f"Failed to withdraw ${withdrawal_amount}; insufficient funds")
            return self.balance

    def transfer(self, amount, recipient):
        if isinstance(recipient, BankAccount):
            if self.balance >= amount:
                self.balance -= amount
                recipient.balance += amount
                self.history.append(f"Transferred ${amount} to {recipient.name}")
                recipient.history.append(f"Received ${amount} from {self.name}")
                return self.balance
            else:
                self.history.append("Insufficient funds, failed to transfer")
                return self.balance
        else:
            print("Not a valid bank account!")
            return self.balance

    def get_balance(self):
        return self.balance

    def get_history(self):
        return self.history

    # Getter and setter for balance
    @property
    def balance(self):
        return self._balance

    @balance.setter
    def balance(self, balance):
        try:
            self._balance = float(balance)
        except ValueError:
            print("Enter numbers")
            self._balance = 0.0

    # Getter and setter for name
    @property
    def name(self):
        return self._name

    @name.setter
    def name(self, name):
        if not name:
            print("Missing name!")
            self._name = "Unnamed"
        else:
            self._name = name


def main():
    # Create accounts
    alice = BankAccount("Alice", 100)
    bob = BankAccount("Bob", 50)

    # Test basic operations
    alice.deposit(25)
    alice.withdraw(10)
    alice.withdraw(200)  # Should fail

    # Test transfer
    alice.transfer(30, bob)

    # Inspect results
    print("Alice balance:", alice.get_balance())   # Expected: 85
    print("Bob balance:", bob.get_balance())       # Expected: 80

    print("\nAlice history:")
    for line in alice.get_history():
        print(line)

    print("\nBob history:")
    for line in bob.get_history():
        print(line)


if __name__ == "__main__":
    main()

And the subclasses got their own __str__ and __repr__ too:

class CheckingAccount(BankAccount):
    def __init__(self, name, balance, overdraft_limit = 16):
        super().__init__(name, balance)
        self.overdraft_limit = overdraft_limit

    def __str__(self):
        return f"This is the Checking Account, the name of the owner is {self.name} and the balance is {self.balance}."

    def __repr__(self):
        return f"Checking Account: (name = {self.name}, balance = {self.balance}, overdraft_limit = {self.overdraft_limit})"

    def withdraw(self, amount):
        if self.balance >= amount:
            self.balance -= amount
            self.history.append(f"Amount {amount} withdrawn from {self.name} account. Total Balance = ${self.balance}")
            return self.balance
        else:
            if self.balance - amount -35 < -self.overdraft_limit:
                self.history.append(f"Withdrawal rejected! exceeded the overdraft limit")
                return self.balance
            self.balance -= (amount + 35)
            self.history.append(f"Overdraft: Withdrew ${amount} with $35 fee. New balance: ${self.balance}")
            return self.balance

    def transfer(self, amount, recipient):
        if isinstance(recipient, BankAccount):
            if self.balance >= amount:
                self.balance -= amount
                recipient.balance += amount
                self.history.append(f"Transferred ${amount} to {recipient.name}")
                recipient.history.append(f"Received ${amount} from {self.name}")
                return self.balance
            self.balance -= (amount + 35)
            self.history.append(f"Overdraft: Tansferred ${amount} with $35 fee to {recipient.name}. New balance: ${self.balance}")
            recipient.balance += amount
            self.history.append(f"Received ${amount} from {self.name}")
            return self.balance
        else:
            print("Not a valid bank account!")
            return self.balance

class SavingsAccount(BankAccount):
    def __init__(self, name, balance, intrest_rate = 0.02):
        super().__init__(name, balance)
        self.intrest_rate = intrest_rate

    def __str__(self):
        return f"This is the Savings Account, the name of the owner is {self.name} and the balance is {self.balance}."

    def __repr__(self):
        return f"Savings Account: (name = {self.name}, balance = {self.balance}, intrest_rate = {self.intrest_rate})"

    def apply_intrest(self):
        intrest = self.balance * self.intrest_rate
        self.balance += intrest
        self.history.append(f"Interest applied: ${intrest}. New balance: ${self.balance}")
        return self.balance


def main():

    # --- Checking Account Tests ---
    print("=== Checking Account ===")
    checking = CheckingAccount("Alice", 100, overdraft_limit=100)

    checking.withdraw(50)      # Normal: balance 50
    checking.withdraw(80)      # Overdraft: balance -65 (80 + 35 fee)
    checking.withdraw(100)     # Exceeds overdraft limit: should fail, balance stays -65
    checking.deposit(20)       # Balance -45

    print("Checking balance:", checking.get_balance())  # Expected: -45
    print("Checking history:")
    for line in checking.get_history():
        print(line)

    # --- Savings Account Tests ---
    print("\n=== Savings Account ===")
    savings = SavingsAccount("Bob", 1000, intrest_rate=0.05)
    savings.apply_intrest()     # Balance 1050
    savings.withdraw(2000)       # Should fail (no overdraft)
    savings.withdraw(50)         # Balance 1000

    print("Savings balance:", savings.get_balance())  # Expected: 1000
    print("Savings history:")
    for line in savings.get_history():
        print(line)

    # --- Cross-account Transfer ---
    print("\n=== Cross-Account Transfer ===")
    checking2 = CheckingAccount("Charlie", 50, overdraft_limit=100)
    savings2 = SavingsAccount("Dana", 200, intrest_rate=0.02)

    checking2.transfer(75, savings2)   # Charlie overdrafts by 25 + 35 fee. Dana receives 75.
    print("Charlie balance:", checking2.get_balance())   # Expected: -60
    print("Dana balance:", savings2.get_balance())       # Expected: 275

if __name__ == "__main__":
    main()

The distinction between __str__ and __repr__ took a while to settle:

__str__ is for humans — print(account) should give readable output
__repr__ is for developers — repr(account) should give enough detail to reconstruct the object
__eq__ lets account1 == account2 mean something real: same name, same balance

Before dunders, printing an object gave something like <__main__.BankAccount object at 0x7f...>. After dunders, it gives BankAccount(Alice, 85.0). The object speaks for itself.

Day 33 — Composition vs Inheritance: A Library System

This was the conceptual centrepiece of the week. The question: when should classes inherit, and when should they contain each other?

The rule I took away: "is-a" → inheritance. "has-a" → composition.

A CheckingAccount is a BankAccount. Inheritance makes sense.
A Library has Books and Members. Composition makes sense. A library is not a book — it shouldn't inherit from one.

from datetime import datetime, timedelta


class Book:
    def __init__(self, title, author, isbn, is_available=True):
        self.title = title
        self.author = author
        self.isbn = isbn
        self.is_available = is_available

    def __str__(self):
        return f"{self.title} by {self.author} (ISBN: {self.isbn})"

    def mark_borrowed(self):
        self.is_available = False

    def mark_returned(self):
        self.is_available = True


class Member:
    def __init__(self, name, member_id):
        self.name = name
        self.member_id = member_id
        self.loans = []  

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

    def borrow_book(self, book, library):
        """Ask library to loan a book to this member."""
        if not isinstance(book, Book):
            print("Invalid book.")
            return False

        if not book.is_available:
            print("Book is currently not available")
            return False

        # Create the Loan (composition: Loan HAS Book and Member)
        due = (datetime.now() + timedelta(days=14)).strftime("%Y-%m-%d")
        loan = Loan(book, self, due)

        # Track it everywhere
        self.loans.append(loan)
        library.record_loan(loan)
        return True

    def return_book(self, loan, library):
        """Return a specific loan via the library."""
        if loan in self.loans:
            self.loans.remove(loan)
            library.close_loan(loan)
        else:
            print("Loan not found for this member.")


class Loan:
    def __init__(self, book, member, due_date):
        self.book = book          # Loan HAS a Book
        self.member = member      # Loan HAS a Member
        self.due_date = due_date

    def __str__(self):
        return f"Loan: {self.book.title} to {self.member.name}, due {self.due_date}"

    def __repr__(self):
        return f"Loan(book={self.book!r}, member={self.member!r}, due_date={self.due_date!r})"


class Library:
    def __init__(self, name):
        self.name = name
        self.books = []      # Library HAS Books
        self.members = []    # Library HAS Members
        self.loans = []      # Library HAS Loans

    def __str__(self):
        return f"{self.name}: {len(self.books)} books, {len(self.members)} members"

    def add_book(self, book):
        if isinstance(book, Book):
            self.books.append(book)

    def register_member(self, member):
        if isinstance(member, Member):
            self.members.append(member)

    def record_loan(self, loan):
        """Called by Member.borrow_book to register a loan."""
        if isinstance(loan, Loan):
            loan.book.mark_borrowed()
            self.loans.append(loan)

    def close_loan(self, loan):
        """Called by Member.return_book to close a loan."""
        if loan in self.loans:
            loan.book.mark_returned()
            self.loans.remove(loan)

    def get_available_books(self):
        return [book for book in self.books if book.is_available]



if __name__ == "__main__":
    lib = Library("CS50 Library")

    b1 = Book("The C Programming Language", "Kernighan & Ritchie", "9780131103627")
    b2 = Book("Clean Code", "Robert C. Martin", "9780132350884")

    lib.add_book(b1)
    lib.add_book(b2)

    alice = Member("Alice", "M001")
    lib.register_member(alice)

    print("Available before borrow:", [b.title for b in lib.get_available_books()])

    alice.borrow_book(b1, lib)

    print("Available after borrow:", [b.title for b in lib.get_available_books()])
    print("Alice's loans:", alice.loans)

    alice.return_book(alice.loans[0], lib)

    print("Available after return:", [b.title for b in lib.get_available_books()])

Four classes. Each one focused. Each one responsible for exactly its own data:

Book knows if it's available
Member knows their loans
Loan knows its book, member, and due date
Library coordinates everything without owning any individual item's logic

The Loan class is the key insight here. It's the relationship between a Book and a Member, captured as its own object. When a loan is created inside borrow_book(), it's automatically due in 14 days via timedelta(days=14). When it's returned, close_loan() flips the book's availability back. Clean handoffs, no tight coupling.

That list comprehension in get_available_books() — [book for book in self.books if book.is_available] — is Week 3 knowledge powering Week 5 design.

Day 34 — The Week 5 Project: A Task Management System

The final project pulled the whole week together: a task management system with User, Project, and Task objects, property validation using regex, and proper OOP throughout.

from datetime import date
import re

#Build a task management system with users, projects, tasks, deadlines
class User:
    def __init__(self, name):
        self.name = name
        self.projects = {}

    def __str__(self):
        return f"The User name is {self.name}"

    def __repr__(self):
        return f"User: (name = {self.name})"

    def create_project(self, title, deadline):
        project = Project(title, deadline)
        self.projects[project.title] = project
        return project

    def mark_complete(self, project_title):
        project = self.projects[project_title]
        project.completed = True

    def remove_project(self, project_title):
        del self.projects[project_title]

    def show_projects(self):
        for project in self.projects.values():
            status = "overdue" if project.is_overdue else "ok"
            print(f"Project title: {project.title} | Deadline: {project.deadline} | Status: {status}")

    @property
    def name(self):
        return self._name
    @name.setter
    def name(self, name):
        if match := re.search(r"^(\w+ ?)$", name, re.IGNORECASE):
            self._name = match.group(1)
        else:
            raise ValueError("Enter Words!")

class Project:
    def __init__(self, title, deadline, completed = False):
        self.title = title
        self.deadline = deadline
        self.completed = completed
        self.tasks = []

    def __str__(self):
        return f"The Project Title is {self.title} and the deadline is {self.deadline}"

    def __repr__(self):
        return f"Project: (title = {self.title}, deadline = {self.deadline}, completed = {self.completed})"

    def add_task(self, task):
        self.tasks.append(task)

    def remove_task(self, task):
        self.tasks.remove(task)

    def view_tasks(self):
        for task in self.tasks:
            print(task)

    def is_overdue(self):
        return not self.completed and self.deadline < date.today()

    @property
    def deadline(self):
        return self._deadline
    @deadline.setter
    def deadline(self, deadline):
        if match := re.search(r"^(\d{2})/ ?(\d{2})/ ?(\d{4})$", deadline):
            try:
                self._deadline = date(int(match.group(3)), int(match.group(2)), int(match.group(1)))
            except ValueError:
                print("Day should be from 1 - 31, Month must be from 1-12")
        else:
            raise ValueError("Enter the deadline in dd/mm/yyyy")




def main():

    # --- Test User creation and string representation ---
    print("=" * 50)
    print("TEST 1: User Creation")
    print("=" * 50)
    alice = User("Alice")
    print(f"__str__: {alice}")
    print(f"__repr__: {repr(alice)}")
    print()

    # --- Test Project creation via User ---
    print("=" * 50)
    print("TEST 2: Project Creation")
    print("=" * 50)
    website = alice.create_project("Website", "05/06/2026")
    mobile_app = alice.create_project("MobileApp", "01/01/2025")
    print(f"__str__: {website}")
    print(f"__repr__: {repr(website)}") 
    print()

    # --- Test Task management ---
    print("=" * 50)
    print("TEST 3: Task Management")
    print("=" * 50)
    website.add_task("Design homepage")
    website.add_task("Setup database")
    website.add_task("Write API")
    print("Tasks in 'Website':")
    website.view_tasks()

    website.remove_task("Setup database")
    print("\nAfter removing 'Setup database':")
    website.view_tasks()
    print()

    # --- Test Overdue Check ---
    print("=" * 50)
    print("TEST 4: Overdue Check")
    print("=" * 50)
    print(f"Website overdue? {website.is_overdue()}")
    print(f"MobileApp overdue? {mobile_app.is_overdue()}")
    print()

    # --- Test Show Projects ---
    print("=" * 50)
    print("TEST 5: Show All Projects")
    print("=" * 50)
    alice.show_projects()
    print()

    # --- Test Mark Complete ---
    print("=" * 50)
    print("TEST 6: Mark Complete")
    print("=" * 50)
    alice.mark_complete("Website")
    print(f"After marking complete: {repr(website)}")
    print(f"Website overdue? {website.is_overdue()}")
    print()

    # --- Test Remove Project ---
    print("=" * 50)
    print("TEST 7: Remove Project")
    print("=" * 50)
    alice.remove_project("MobileApp")
    alice.show_projects()
    print()

    # --- Test Name Validation ---
    print("=" * 50)
    print("TEST 8: Validation")
    print("=" * 50)
    try:
        bad_user = User("Alice123!!!")
    except ValueError as e:
        print(f"Caught expected error: {e}")

    try:
        bad_project = Project("Bad", "not-a-date")
    except ValueError as e:
        print(f"Caught expected error: {e}")




if __name__ == "__main__":
    main()

This is the most mature code I've written so far. A few things that stand out:

Walrus operator in setters — if match := re.search(...) assigns and tests in one expression. The deadline setter validates and converts a "dd/mm/yyyy" string into a real date object using regex capture groups, raising a proper ValueError if it fails.
is_overdue() uses date.today() — comparing a stored deadline against today's date to compute real status dynamically.
show_projects() calls is_overdue() on each project and reports "overdue" or "ok" without needing any stored status field — the answer is computed live from the data.
Eight structured tests in main() — each labelled, each verifying a specific feature. I started writing tests like this during the week and it immediately made debugging faster.

The walrus operator (:=) was something I found while writing the regex validation and it immediately became my favourite small Python feature. Assign and check in one line. Clean.

📁 What I Built This Week

Project	File	Concepts Used
Bank Account	`bank_account.py`	`__init__`, `__str__`, `@property`, deposit/withdraw/transfer/history
Account Types	`account_types.py`	Inheritance, `super()`, method overriding, overdraft, interest
Dunder Methods	`bank_objects.py` + `account_objects.py`	`__str__`, `__repr__`, `__eq__`, subclass dunders
Library System	`library.py`	Composition, 4 classes, `timedelta`, list comprehension
Task Manager	`tasks.py`	OOP throughout, walrus operator, regex in setters, `date.today()`, 8 test cases

All the code is on GitHub — every week, every file:
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

__init__ sets state, not creates objects. The object exists before __init__ runs. It just gets its starting values there.
super().__init__() is not optional. Forgetting it in a subclass means the parent's attributes don't exist. The error that follows is confusing until you know why.
@property setters are validation layers. They intercept writes and enforce rules before anything gets stored. The object protects itself.
"is-a" vs "has-a" is the real inheritance question. Once I had that frame, every design decision in the library became obvious.
Dunders make objects feel native. print(account) giving BankAccount(Alice, 85.0) instead of a memory address is a small thing that changes everything about working with your own classes.
The walrus operator (:=) is genuinely useful inside property setters — assign the regex match and test it in one expression.

What I Want to Learn Next

Week 6 is coming and I can already see what's missing:

Abstract base classes — enforcing that subclasses implement certain methods
Class methods vs static methods vs instance methods — I've touched @classmethod but not the full picture
APIs — pulling live data from the internet into Python objects
pytest — writing real tests, not just a main() with print statements
A bigger project — something that uses multiple classes across multiple files with real data

Five weeks in. The code is starting to have architecture.

Drop your Week 5 projects in the comments — I want to see how others are tackling OOP for the first time.

See you in Week 6. 🐍

Week 5 complete. Objects everywhere. No going back.

Month 1: From Zero to Building Real Tools.

Om Kolhapure — Mon, 01 Jun 2026 07:09:26 +0000

I Learned Python for 30 Days Straight — Here's Everything I Built

A month ago I had never written a line of Python.

I'd been meaning to start for two years. I finally did.

No bootcamp. No structured course. Just a curriculum I followed day by day, building one project per concept, committing every file to GitHub. Twenty-seven days. Four weeks. One clear theme per week. Over twenty projects, from "Hello, World!" to a class-based personal finance tracker with regex validation, JSON persistence, and CSV exports.

This is the full story.

The Structure: One Theme Per Week

Every week had a focus. Each day had one concept. Each concept ended with a project.

Week	Theme	Days
Week 1	The Basics	1–7
Week 2	Functions & Organisation	8–13
Week 3	Data Structures	15–20
Week 4	Files & Real Programs	22–27

The numbered days have gaps — those were rest or catch-up days. That rhythm mattered more than I expected. Showing up 27 out of 30 days is still 27 days of practice.

Week 1 — Learning the Language

Theme: Python basics. Getting the environment working. Writing the first real programs.

What I learned

print(), input(), f-strings, data types
Variables, string methods, int(), float()
if / elif / else, the match statement
for and while loops
Functions (introduced early, because my projects demanded them)

What I built

Project	Highlight
Hello World + Greeter	Four different ways to print a greeting
String Methods Playground	Every major string method in one file
Calculator	Input validation with `isdecimal()` before the math
Number Guessing Game	Difficulty levels with `match`, loop-based game logic
Multiplication Table	Nested `while` and `for` loops
Password Validator	`any()` with a generator — the first genuinely elegant thing I wrote
Text Adventure Game	Rooms, inventory, random beast, win/lose conditions

The moment that clicked

The password validator using any(char.isupper() for char in password). I found any() while Googling, dropped it in, and it worked perfectly. That kind of side-discovery while building is what makes self-directed learning stick.

Biggest surprise

Python reads like English. I expected cryptic syntax. I got something close to readable logic on day one.

Week 2 — Functions & Organisation

Theme: Writing code that's not just correct, but clean. One function, one job.

What I learned

Function parameters, return values, scope
try / except and error handling
The datetime, random, sys, pathlib modules
File I/O basics — writing and reading with pathlib
Docstrings and sys.exit()

What I built

Project	Highlight
Tip Calculator	`removesuffix()` to handle `$42` or `42` equally
Days-Until Calculator	`try/except ValueError` + `else` on a `try` block
Dice Roller with History	`sys.exit()`, docstrings, session-persistent history list
Password Manager	Caesar cipher encryption, `json` + `pathlib` file persistence
Adventure Game (refactored)	Proper input validation on room names, cleaner `beast()` logic

The moment that clicked

try/except with the else clause. The else block on a try only runs if no exception was raised. I didn't know it existed. The moment I used it for the break in the days-until calculator, it felt like discovering a hidden tool.

Biggest surprise

Refactoring Week 1 code wasn't boring — it was genuinely satisfying. Seeing messy scripts become clean, purposeful functions felt like real progress.

Week 3 — Data Structures

Theme: Designing programs around data, not the other way around.

What I learned

Lists — append(), remove(), pop(), index(), filtering
List comprehensions
Dictionaries — nested, .items(), .values(), del
Sets and tuples — when to use each
Multi-file project structure — splitting data and logic into separate modules

What I built

Project	Highlight
To-Do List App	`pop().append()` chain to move tasks between lists in one line
Number Filter	List comprehensions + prime algorithm using `pow(n, 0.5)`
Contact Book	Nested dictionaries — name → phone, email, address
Inventory System	Three levels of nesting — category → item → details
Python Quiz App	Tuples for immutable data, `dict(zip())`, multi-file structure, high score persisted to file

The moment that clicked

dict(zip(qdata.markers, qdata.options[val])) in the quiz app. Zipping two lists into a dictionary on a single line, then using it to map A/B/C/D to options dynamically. That felt like writing real Python, not tutorial Python.

Biggest surprise

Data structures aren't just storage — they're design decisions. Choosing a tuple over a list, or a dictionary over a list of lists, shapes the entire program. I started thinking about the shape of data before writing functions.

Week 4 — Files & Real Programs

Theme: Programs that do something permanent. Files, formats, real-world data handling.

What I learned

File I/O — open(), read/write/append modes, os.remove()
The csv module — DictWriter, DictReader, delete-and-rewrite pattern
JSON as a lightweight database — json.dumps() and json.loads()
Regular expressions — re.fullmatch(), re.search(), re.findall(), capture groups
Object-Oriented Programming intro — class, @classmethod, grouping methods

What I built

Project	Highlight
Note-Taking App	Full CRUD — create, view, update, delete — persisted to `.txt` files
Expense Tracker	CSV write/read with `DictWriter` / `DictReader`, delete-and-rewrite
Email Validator	`re.fullmatch()` regex pattern + `email-validator` library comparison
Log Parser	`re.findall()` with capture groups extracting IPs and timestamps from real log data
Personal Finance Tracker	JSON + CSV + regex + full CRUD + monthly report generation + CSV export
Finance Tracker (OOP)	Same app, refactored into a `Finance` class with `@classmethod` methods

The moment that clicked

The log parser. Eight lines of code. A regex pattern. An access.log file. Output: clean IP address and timestamp pairs extracted from every line. That's when regex stopped feeling like noise and started feeling like a superpower.

Biggest surprise

OOP is about grouping, not just syntax. Wrapping finance.py functions into a Finance class didn't change what the code does — it changed how it's organised. That distinction, once I saw it, changed how I think about designing programs.

Everything I Built in 30 Days

#	Project	Week	Key Concepts
1	Hello World + Greeter	1	`print()`, `input()`, f-strings
2	String Methods Playground	1	String methods
3	Calculator	1	Input validation, `if/elif/else`
4	Number Guessing Game	1	`while`, `random`, `match`
5	Multiplication Table	1	`for` loop, nested `while`
6	Password Validator	1	`any()`, string methods
7	Text Adventure Game	1	Functions, global state, game logic
8	Tip Calculator	2	Functions, `return`, `removesuffix()`
9	Days-Until Calculator	2	`try/except`, `datetime`
10	Dice Roller with History	2	`random`, `sys`, docstrings
11	Password Manager	2	File I/O, `json`, Caesar cipher
12	To-Do List App	3	Lists, filtering, `match`
13	Number Filter	3	List comprehensions, prime algorithm
14	Contact Book	3	Nested dictionaries
15	Inventory System	3	3-level nested data
16	Python Quiz App	3	Tuples, `zip()`, multi-file modules
17	Note-Taking App	4	File CRUD, `os`, `if __name__`
18	Expense Tracker	4	`csv`, `DictWriter`, `DictReader`
19	Email Validator	4	`re.fullmatch()`, regex
20	Log Parser	4	`re.findall()`, capture groups
21	Personal Finance Tracker	4	JSON + CSV + regex + full CRUD
22	Finance Tracker (OOP)	4	`class`, `@classmethod`

All of it is on GitHub:
👉 github.com/Omk4314/progress-on-python

What Changed in 30 Days

How I think about errors. Week 1 me panicked at red text. Month 1 me reads the traceback, identifies the line, and knows where to look. Errors are information, not failures.

How I think about data. I used to design code and shove data into variables. Now I design the data structure first and write functions around it. That inversion came somewhere in Week 3 and never went away.

How I think about programs. Week 1 programs ran once and died. Week 4 programs write to files, read them back, export CSV reports, validate inputs with regex, and persist high scores between sessions. They feel like software.

How I think about code quality. The first version of anything I write now has one job per function, docstrings, guard clauses, and if __name__ == "__main__":. None of that was natural on Day 1. All of it is by Day 27.

What I'd Tell Myself on Day 1

Build things, don't just read about them. Every concept landed harder when it was inside a real project.
Commit every day, even the small days. The GitHub streak is a chain worth keeping.
Google while building, not before. I learned any(), removesuffix(), dict(zip()), and re.findall() by searching for solutions to problems I was actually stuck on.
Refactoring old code is progress. Going back to Week 1 files in Week 2 and making them better wasn't busy work. It was consolidation.
The terminal stops being scary faster than you think. By Day 5 I was looking forward to opening it.

What's Next

Month 2 has a clear agenda:

OOP properly — __init__, instance variables, inheritance, __str__, __repr__
APIs — pulling real data from the internet into Python programs
pip and virtual environments — managing dependencies like a real project
Testing — writing pytest tests for my own code
A multi-file project — something big enough to need proper architecture

One month down. The foundation is solid. Time to build something on top of it.

If you're learning Python alongside me, drop a comment — I want to see what you're building too.

See you in Month 2. 🐍

30 days. 22 projects. One language. Still going.

What I Learned in Week 4 of Python — Files, Real Programs & My First Class

Om Kolhapure — Mon, 01 Jun 2026 07:02:49 +0000

Week 4 had a different energy.

The programs stopped feeling like exercises and started feeling like tools I'd actually use. A note-taking app that persists files to disk. An expense tracker that exports to CSV. A finance tracker that generates monthly reports. And then — at the very end — rewriting that finance tracker using a class for the first time.

One month of Python. Here's how Week 4 went.

Day 22 — File I/O: A Note-Taking App

The note-taking app was the first project I built where I genuinely thought: I would actually use this.

CRUD — Create, Read, Update, Delete — all persisted to real .txt files on disk. Title becomes filename. Notes survive after the program closes. The whole thing hinges on two small helper functions that every other function calls:

import sys
import os

def main():
    print("\tWelcome to notes\n")
    while True:
        print("What would you like to do?")
        while True:
            user_response = input("1.Add a new note\n2.view a note\n3.update a note\n4.Delete a note\n Press 'q' to quit\n-> ")
            if user_response in ("1", "2", "3", "4", "q"):
                break
        match user_response:
            case "1":
                add_note()
            case "2":
                if read_notes().strip() == "":
                    print("No note found, try adding a note first!")
                else:
                    view_note()
            case "3":
                if read_notes().strip() == "":
                    print("No note found, try adding a note first!")
                else:
                    update_note()
            case "4":
                if read_notes().strip() == "":
                    print("No note found, try adding a note first!")
                else:
                    delete_note()
            case "q":
                sys.exit()


def add_note():
    '''Creates a new txt file and asks user for title as the name of file and content of the file'''
    usr_title = input("Enter title: "\").strip().title()"
    if usr_title in read_notes():
        print("File Already exists")
    else:
        store_notes(usr_title)
        usr_content = input("Write here:\n")
        with open(f"{usr_title}.txt", "w") as file:
            file.write(usr_content)
            print("Saved")
        print(read_notes())

def view_note():
    '''Displays existing notes to the user and asks the user to select a note to read'''
    print(read_notes())
    usr_note = input("Enter the name of the note you want to view: ").strip().title()
    if usr_note in read_notes():
        with open(f"{usr_note}.txt") as file:
            print(file.read())
    else:
        print("Note not found!")


def update_note():
    '''Displays the saved notes to the user and asks user for the file and the content to update'''
    print(read_notes())
    select_note = input("Enter the name of the note you want to update: ").strip().title()
    if select_note in read_notes():

        with open(f"{select_note}.txt") as f_ile:
            print(f_ile.read())
        new_content = input("Write new text here:\n")    
        with open(f"{select_note}.txt", "a") as file:
            file.write(f"\n{new_content}")
            print("saved")
        with open(f"{select_note}.txt") as f:
            print(f.read())
    else:
        print("Note not found!")


def delete_note():
    '''Displays notes to the user and asks him to enter the name of a note user wants to delete'''
    print(read_notes())
    del_note = input("Enter the name of the note you want to delete: ").strip().title()
    if del_note in read_notes():
       os.remove(f"{del_note}.txt")
    else:
        print("Note not found!")


def store_notes(note):
    '''Stores the title of the note provided by the user to keep track of notes'''
    with open("notes.txt", "a") as app_file:
        app_file.write(f"{note}\n")


def read_notes():
    with open("notes.txt") as app_file:
        return app_file.read()

if __name__ == "__main__":
    main()

Three things I'm proud of here:

store_notes() and read_notes() act as a lightweight index. Every note title gets written to notes.txt so the app always knows what files exist without scanning the directory.
Guard checks before every operation — if read_notes().strip() == "": in main() catches the "no notes yet" case cleanly before passing control to any function.
if __name__ == "__main__": — this is the first time I used it properly. It means the app only runs when executed directly, not when imported as a module. A small habit that makes code more reusable.

Day 23 — CSV Handling: An Expense Tracker

Day 23 was about the csv module — Python's built-in tool for reading and writing spreadsheet-compatible files. I built an expense tracker that writes to a named CSV file, reads it back, and deletes rows:

import csv
import sys
import os


def main():
    print("\n\tWelcome to expense tracker!")
    print("What would you like to do?")
    main_file = tracker_file()
    while True:
        user_response = input("1.Add expense\n2.View expenses\n3.Delete an expense\nEnter 'q' to quit\n-> ")
        if user_response in ("1", "2", "3", "q"):   
            match user_response:
                case "1":
                    add_expense(main_file)
                case "2":
                    view_expense(main_file)
                case "3":
                    delete_expense(main_file)
                case "q":
                    sys.exit()

def tracker_file():
    file_name = input("Enter the file name you want to save your expenses into: ").strip().title()
    if os.path.isfile(f"{file_name}.csv"):
        print("File Already exists")
    else:
        with open(f"{file_name}.csv", "a") as expense_file:
            column_title = csv.writer(expense_file)
            column_title.writerow(["Category","Expense"])
    return f"{file_name}.csv"

def add_expense(main_file):
    '''Adds expense category to the csv file in category column and expense in expense column'''
    while True:
        user_category = input("Enter the category of the expense: ").strip().title()
        user_expense = input("Enter your expense: ").strip()
        if user_category.isspace() or user_expense.isspace():
            print("The field cannot be empty")
        elif user_category.isdecimal() or user_expense.isalpha():
            print("Category takes the category of expense!")
            print("Expense takes the expense on the category!")
        else:
            break
    with open(main_file, "a", newline = "") as add_file:
        adder = csv.DictWriter(add_file, fieldnames = ["Category", "Expense"], lineterminator = "\n")
        adder.writerow({"Category": user_category, "Expense": user_expense})

def view_expense(main_file):
    '''Shows the user his expenses'''
    if os.path.isfile(main_file):
        with open(main_file) as view_file:
            viewer = csv.DictReader(view_file)
            for row in viewer:
                print(f"{row['Category']}:- {row['Expense']}")
    else:
        print("No file found!")


def delete_expense(main_file):
    view_expense(main_file)
    if os.path.isfile(main_file):
        ask_user = input("\nEnter the category of the expense you want to delete: ").strip().title()
        with open(main_file) as del_file:
            reader = list(csv.reader(del_file))
            for row in reader:
                if ask_user in row:
                    reader.remove(row)
                else:
                    print("Category not found!")
        with open(main_file, "w", newline = "") as deleted_file:
            writer = csv.writer(deleted_file, lineterminator = "\n")
            writer.writerows(reader)
        print("Deleted")
    else:
        print("No file found!")


if __name__ == "__main__":
    main()

The delete_expense() function taught me the standard pattern for editing a CSV: read everything into memory as a list, remove the unwanted row, then write the whole list back. You can't surgically remove a line from a CSV file — you rewrite the whole thing. Once you know that, the pattern makes complete sense.

csv.DictWriter and csv.DictReader were the real discovery here — working with rows as dictionaries (row['Category']) instead of indexes (row[0]) makes the code read like the data it represents.

Day 24 — JSON & Data Persistence

Day 24 was about json — specifically using it as a lightweight database. The insight: JSON is just a string format for Python dictionaries. json.dumps() converts a dictionary to a string you can write to a file. json.loads() converts it back.

This pattern became the backbone of the finance tracker (Day 26) — every transaction is stored as a JSON line in report.txt, one dictionary per line. Reading it back is just a loop over file.readlines() with json.loads() on each line.

Writing structured data as JSON instead of plain text means you can store a full dictionary — date, type, category, amount, description — in a single line and retrieve it perfectly. No parsing, no splitting on commas, no guessing field positions.

Day 25 — Regular Expressions

Regex was the topic I'd been most nervous about. The syntax looks like a password generator exploded. But once I slowed down and built two programs to apply it, the logic clicked.

Email Validator

import re 

def main():
    user_email = input("Enter your email: ").strip()
    email_validator(user_email)


def email_validator(email):
    if re.fullmatch(r"\w+@(\w+\.)?\w+\.\w{3}", email, re.IGNORECASE):
        print("Valid")
    else:
        print("Invalid")

if __name__ == "__main__":
    main()

Then I went further and built a more robust version using the email-validator library:

from email_validator import validate_email, EmailNotValidError
mail = input("Enter your email: ").strip()
try:
    validate_email(mail)
    print("Valid Email")
except EmailNotValidError:
    print("Invalid Email")

Two approaches, two lessons: regex gives you control and portability; a dedicated library gives you correctness out of the box. Both have their place.

Log Parser

The log parser was where regex went from "I understand this" to "I can actually use this":

import re
ip_re = r"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*(\[\d{2}/[a-z^hikwxz]{3}/\d{4}:\d{2}:\d{2}:\d{2} [+-]{1}\d{4}\])"
with open("access.log") as log_file:
    contents = log_file.read()
match = re.findall(ip_re, contents, re.IGNORECASE)
for required_value in match:
    print(f"IP address: {required_value[0]} | Timestamp: {required_value[1]}")

That single pattern extracts both the IP address and the timestamp from every line of a server log file. re.findall() returns a list of tuples — each tuple is one match, with group 1 (IP) and group 2 (timestamp) as elements.

The [a-z^hikwxz]{3} part matches a three-letter month abbreviation while excluding letters that don't appear in any month name. That kind of precision in a pattern is what makes regex so powerful — and so worth learning.

Day 26 — The Mini-Project: Personal Finance Tracker

Day 26 brought everything together: file I/O, JSON persistence, CSV export, regex date validation, and a clean menu-driven architecture. This is the most complete program I've built.

Features:

💰 Add income and expense transactions with date, category, amount, description
📊 View a monthly report — income, expenses, net balance — filtered by month
📁 Export any month's report to a formatted CSV file
🗑️ Delete individual transactions or entire reports
✅ Regex validates every date before it's saved

import csv
import json
import os
import re
import sys

def main():
    '''Main function'''
    print("===Personal Finance Tracker===")
    print("What would youy like to do?")
    print("SELECT THE CORRESPONDING NUMBER FOR THE GIVEN OPREATION")
    while True:
        while True:
            usr_response = input("1. Add Transaction\n2. View Monthly Report\n3. Export Report To CSV\n4.Delete Transaction\n5.Delete Report\n6.Exit\n--> ").strip()
            if usr_response in ("1", "2", "3", "4", "5", "6"):
                break
        match usr_response:
            case "1":
                add_transaction()
            case "2":
                view_report()
            case "3":
                export_report()
            case "4":
                delete_trans()
            case "5":
                delete_report()
            case "6":
                sys.exit()


def add_transaction():
    '''Adds the user transaction to a file as a dictionary'''
    while True:
        input_date = input("Enter the transaction date(dd/mm/yyyy): ").strip()
        if re.search(r"^\d{1,2}/ ?\d{1,2}/ ?\d{4}$", input_date):
            trans_date = input_date
            break
        else:
            print("Enter date in dd/mm/yyyy format!")
    while True:
        trans_type = input("Is it income or expense? ").strip().lower()
        if trans_type in ("income", "expense"):
            break

    trans_category = input("Enter the category you did the transaction for: ").strip().title()

    while True:
        try:
            trans_amount = float(input("Enter transaction amount: ").strip())
            break
        except ValueError:
            print("Enter the numbers!")

    while True:
        ask_user = input("Do you want to add a description[Y/N]? ").strip().upper()
        if ask_user in ("Y", "N"):
            break
    if ask_user == "Y":
        trans_descrp = input("Enter transaction description\n--> ")
    else:
        trans_descrp = None

    transaction = {"date": trans_date, "type": trans_type, "category": trans_category, "amount": trans_amount, "description": trans_descrp}
    with open("report.txt", "a") as report_file:
        report_file.write(f"{json.dumps(transaction)}\n")


def view_report():
    '''Shows monthy income and monthly expense and net balance and returns the user input'''
    view_income = []
    view_expense = []
    total_income = 0
    total_expense = 0
    while True:
        view_month = input("Enter the month and year of the transaction(mm/yyyy): ").strip()
        if re.search(r"^\d{1,2}/ ?\d{4}$", view_month):
            break
        else:
            print("Enter in the mm/yyyy format!")
    with open("report.txt") as view_file:
        lines = view_file.readlines()
        if not lines:
            print("No Transactions To View!")
        else:
            for trans_dict in lines:
                view_dict = json.loads(trans_dict)
                if view_month == re.search(r"^\d{1,2}/ ?(\d{1,2}/ ?\d{4})$", view_dict['date']).group(1):
                    if view_dict['type'] == "income":
                        view_income.append(f"\t{view_dict['category']}: {view_dict['amount']}\n")
                        total_income += view_dict['amount']
                    else:
                        view_expense.append(f"\t{view_dict['category']}: {view_dict['amount']}\n")
                        total_expense += view_dict['amount']

                    print(f"===REPORT FOR {view_month}===")
                    for income_trans in view_income:
                        print("Income:")
                        print(income_trans)
                    print(f"Total Income: ${total_income}")
                    for expense_trans in view_expense:
                        print("Expenses: ")
                        print(expense_trans)
                    print(f"Total Expenses: ${total_expense}\n")
                    print(f"Net Balance: ${total_income - total_expense}")
    return view_month, total_income, total_expense


def export_report():
    '''Exports monthly report to csv'''
    trans_month, total_income, total_expense = view_report()
    safe_month = trans_month.replace("/", "_")
    if total_income == 0 and total_expense == 0:
        print("No Transactions to Export!")
    else:
        if os.path.isfile(f"Report_{safe_month}.csv"):
            print("Report already exported!")
        else:
            with open(f"Report_{safe_month}.csv", "a", newline = "") as export_file:
                writer = csv.DictWriter(export_file, fieldnames = ["Type", "Category", "Description", "Amount"], lineterminator = "\n")
                writer.writeheader()
                with open("report.txt") as info_file:
                    for info_dict in info_file.readlines():
                        new_dict = json.loads(info_dict)
                        if trans_month == re.search(r"^\d{1,2}/ ?(\d{1,2}/ ?\d{4})$", new_dict['date']).group(1):
                            writer.writerow({'Type': new_dict['type'], 'Category': new_dict['category'], 'Description': new_dict['description'], 'Amount': new_dict['amount']})

                total_writer = csv.writer(export_file, lineterminator = "\n")
                total_writer.writerows([[None, None, "Total Income", total_income],
                                        [None, None, "Total Expense", total_expense],
                                        [None, None, "Net Balance", total_income - total_expense]])    


def delete_trans():
    delete_cat = input("Enter category of the transaction you want to delete: ").strip()
    delete_date = input("Enter the date of the transaction you want to delete(dd/mm/yyyy)")
    remaining_trans = []
    if os.path.isfile("report.txt"):
        with open("report.txt") as del_file:
            trans_lines = del_file.readlines()
            for trans_line in trans_lines:
                Dict = json.loads(trans_line)
                if delete_cat not in Dict.values() and delete_date not in Dict.values():
                    remaining_trans.append(Dict)

        with open("report.txt", "W") as new_file:
            for data in remaining_trans:
                new_file.write(f"{json.dumps(data)}\n")
    else:
        print("No transaction to delete try adding a transaction!")

def delete_report():
    ask_report = input("Enter the name of the report you want to delete: ")
    if os.path.isfile(f"{ask_report}.csv"):
        os.remove(f"{ask_report}.csv")
    else:
        print("NO Report Found With The Given Name")

if __name__ == "__main__":
    main()

The export_report() function was the most satisfying to get working. It calls view_report() first to get the month and totals, then writes every matching transaction as a CSV row, and appends summary rows at the end. Open the exported file in Excel and it's a clean, formatted monthly report.

Regex appears three times in this program — validating the transaction date on input, validating the month filter, and extracting the month/year portion from each stored date for comparison. By Day 26, regex had stopped feeling foreign and started feeling useful.

Day 27 — OOP: Rewriting the Finance Tracker with a Class

The final day of Week 4 — and of the month — was about Object-Oriented Programming. The task: take finance.py and reorganise it into a Finance class.

Same functionality. Different structure. Here's what changed:

import csv
import json
import os
import re
import sys

class Finance:
    @classmethod
    def add_transaction(cls):
        '''Adds the user transaction to a file as a dictionary'''
        while True:
            input_date = input("Enter the transaction date(dd/mm/yyyy): ").strip()
            if re.search(r"^\d{1,2}/ ?\d{1,2}/ ?\d{4}$", input_date):
                trans_date = input_date
                break
            else:
                print("Enter date in dd/mm/yyyy format!")
        while True:
            trans_type = input("Is it income or expense? ").strip().lower()
            if trans_type in ("income", "expense"):
                break

        trans_category = input("Enter the category you did the transaction for: ").strip().title()

        while True:
            try:
                trans_amount = float(input("Enter transaction amount: ").strip())
                break
            except ValueError:
                print("Enter the numbers!")

        while True:
            ask_user = input("Do you want to add a description[Y/N]? ").strip().upper()
            if ask_user in ("Y", "N"):
                break
        if ask_user == "Y":
            trans_descrp = input("Enter transaction description\n--> ")
        else:
            trans_descrp = None

        transaction = {"date": trans_date, "type": trans_type, "category": trans_category, "amount": trans_amount, "description": trans_descrp}
        with open("report.txt", "a") as report_file:
            report_file.write(f"{json.dumps(transaction)}\n")

    @classmethod
    def view_report(cls):
        '''Shows monthy income and monthly expense and net balance and returns the user input'''
        view_income = []
        view_expense = []
        total_income = 0
        total_expense = 0
        while True:
            view_month = input("Enter the month and year of the transaction(mm/yyyy): ").strip()
            if re.search(r"^\d{1,2}/ ?\d{4}$", view_month):
                break
            else:
                print("Enter in the mm/yyyy format!")
        with open("report.txt") as view_file:
            lines = view_file.readlines()
            if not lines:
                print("No Transactions To View!")
            else:
                for trans_dict in lines:
                    view_dict = json.loads(trans_dict)
                    if view_month == re.search(r"^\d{1,2}/ ?(\d{1,2}/ ?\d{4})$", view_dict['date']).group(1):
                        if view_dict['type'] == "income":
                            view_income.append(f"\t{view_dict['category']}: {view_dict['amount']}\n")
                            total_income += view_dict['amount']
                        else:
                            view_expense.append(f"\t{view_dict['category']}: {view_dict['amount']}\n")
                            total_expense += view_dict['amount']

                        print(f"===REPORT FOR {view_month}===")
                        for income_trans in view_income:
                            print("Income:")
                            print(income_trans)
                        print(f"Total Income: ${total_income}")
                        for expense_trans in view_expense:
                            print("Expenses: ")
                            print(expense_trans)
                        print(f"Total Expenses: ${total_expense}\n")
                        print(f"Net Balance: ${total_income - total_expense}")
        return view_month, total_income, total_expense

    @classmethod
    def export_report(cls):
        '''Exports monthly report to csv'''
        trans_month, total_income, total_expense = Finance.view_report()
        safe_month = trans_month.replace("/", "_")
        if total_income == 0 and total_expense == 0:
            print("No Transactions to Export!")
        else:
            if os.path.isfile(f"Report_{safe_month}.csv"):
                print("Report already exported!")
            else:
                with open(f"Report_{safe_month}.csv", "a", newline = "") as export_file:
                    writer = csv.DictWriter(export_file, fieldnames = ["Type", "Category", "Description", "Amount"], lineterminator = "\n")
                    writer.writeheader()
                    with open("report.txt") as info_file:
                        for info_dict in info_file.readlines():
                            new_dict = json.loads(info_dict)
                            if trans_month == re.search(r"^\d{1,2}/ ?(\d{1,2}/ ?\d{4})$", new_dict['date']).group(1):
                                writer.writerow({'Type': new_dict['type'], 'Category': new_dict['category'], 'Description': new_dict['description'], 'Amount': new_dict['amount']})

                    total_writer = csv.writer(export_file, lineterminator = "\n")
                    total_writer.writerows([[None, None, "Total Income", total_income],
                                            [None, None, "Total Expense", total_expense],
                                            [None, None, "Net Balance", total_income - total_expense]])    

    @classmethod
    def delete_trans(cls):
        delete_cat = input("Enter category of the transaction you want to delete: ").strip()
        delete_date = input("Enter the date of the transaction you want to delete(dd/mm/yyyy)")
        remaining_trans = []
        if os.path.isfile("report.txt"):
            with open("report.txt") as del_file:
                trans_lines = del_file.readlines()
                for trans_line in trans_lines:
                    Dict = json.loads(trans_line)
                    if delete_cat not in Dict.values() and delete_date not in Dict.values():
                        remaining_trans.append(Dict)

            with open("report.txt", "W") as new_file:
                for data in remaining_trans:
                    new_file.write(f"{json.dumps(data)}\n")
        else:
            print("No transaction to delete try adding a transaction!")

    @classmethod
    def delete_report(cls):
        ask_report = input("Enter the name of the report you want to delete: ")
        if os.path.isfile(f"{ask_report}.csv"):
            os.remove(f"{ask_report}.csv")
        else:
            print("NO Report Found With The Given Name")

def main():
    '''Main function'''
    print("===Personal Finance Tracker===")
    print("What would youy like to do?")
    print("SELECT THE CORRESPONDING NUMBER FOR THE GIVEN OPREATION")
    user_finance = Finance()
    while True:
        while True:
            usr_response = input("1. Add Transaction\n2. View Monthly Report\n3. Export Report To CSV\n4.Delete Transaction\n5.Delete Report\n6.Exit\n--> ").strip()
            if usr_response in ("1", "2", "3", "4", "5", "6"):
                break
        match usr_response:
            case "1":
                Finance.add_transaction()
            case "2":
                Finance.view_report()
            case "3":
                Finance.export_report()
            case "4":
                Finance.delete_trans()
            case "5":
                Finance.delete_report()
            case "6":
                sys.exit()


if __name__ == "__main__":
    main()

Everything is now a method inside the Finance class. Calling Finance.add_transaction() instead of just add_transaction() is a small syntax change with a big conceptual difference — the behaviour belongs to the class. It's the first step toward proper OOP thinking.

@classmethod means the method is called on the class itself rather than on an instance. This is my introduction to that concept and I know there's more — __init__, instance variables, inheritance — that I haven't touched yet. But having a class that groups related behaviour together already makes the code feel more organised.

📁 What I Built This Week

Project	File	Concepts Used
Note-Taking App	`notes.py`	File I/O, `open()`, `os.remove()`, `if __name__`
Expense Tracker	`expenses.py`	`csv`, `DictWriter`, `DictReader`, delete-and-rewrite
Email Validator	`validator.py` + `robust_validator.py`	`re.fullmatch()`, `email-validator` library
Log Parser	`log_parser.py`	`re.findall()`, capture groups, complex patterns
Personal Finance Tracker	`finance.py`	JSON persistence, CSV export, regex validation, full CRUD
Finance Tracker (OOP)	`finance_cls.py`	`class`, `@classmethod`, OOP refactoring

All the code is on GitHub — every week, every file:
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

File I/O is what makes programs real. The moment notes survive after the terminal closes, it stops being a script and starts being software.
JSON + files = a lightweight database. No setup, no dependencies — just structured data written line by line and read back perfectly.
Regex is a language inside a language. Intimidating at first, genuinely powerful once it clicks. The log parser going from raw text to clean IP + timestamp pairs in eight lines is still satisfying.
OOP is about grouping, not just syntax. Wrapping functions into a class didn't change what the code does — it changed how it's organised. That distinction matters.
if __name__ == "__main__": is a habit worth building early. Every project file has it now.

What I Want to Learn Next

Month 2 is going to go further:

OOP properly — __init__, instance variables, inheritance, __str__
APIs — pulling real live data into Python
Virtual environments and pip — managing dependencies like a real project
Testing — pytest, writing tests for my own code
A bigger project — something multi-file, with real users and real data

One month done. See you in Month 2. 🐍

Week 4 complete. Month 1 complete. The programs are real now.

Week 3: Lists, Dicts, and Why Data Structures Matter.

Om Kolhapure — Tue, 26 May 2026 17:21:23 +0000

Weeks 1 and 2 were about learning the language.

Week 3 was about learning how to hold data.

Every meaningful program stores and organises information — lists of tasks, books of contacts, inventories of products. This week I stopped treating data as a side effect of my programs and started designing programs around data. Lists, dictionaries, nested structures, sets, tuples — six days that changed how I think about writing Python.

Here's what happened.

Day 15 — Lists Deep Dive: A Real To-Do App

Day 15 started with a question: what's the most practical thing I can build with a list?

A to-do app. Add tasks, remove them, mark them complete, filter by status. I built the whole thing using list methods — append(), remove(), pop(), index() — and kept the clean one-function-one-job structure I picked up in Week 2:

import sys

pending_tasks = []
completed_tasks = []


def main():
    print("\n\tWelcome to the app!")
    while True:
        while True:
            usr = input('''What would you like to do?(choose the corresponding number)\n1.Add Tasks
                        \n2.Mark complete\n3.View Tasks\n4.Remove Task\n5.Press 'q' to quit\n-> ''')

            if usr == "1" or usr == "2" or usr == "3" or usr == "4" or usr == "q":
                break
        match usr:
            case "1":
                add_task()
            case "2":
                mark_complete()
            case "3":
                filters()
            case "4":
                remove_task()
            case "q":
                sys.exit()


#Add
def add_task():
    '''Adds Task to pending_tasks'''
    new_task = input("Enter the new task: ").strip()
    pending_tasks.append(new_task)
    print("Task Added")
    print_tasks(pending_tasks)


#Remove
def remove_task():
    '''Removes the Task mentioned by the user'''
    rmove = input("Enter the task you want to remove: ").strip()
    if rmove in pending_tasks:
        pending_tasks.remove(rmove)
        print_tasks(pending_tasks)
    elif rmove in completed_tasks:
        completed_tasks.remove(rmove)
        print_tasks(completed_tasks)
    else:
        print("Task not found!")


#Mark Complete
def mark_complete():
    '''Transfers the task completed by the user from pending_tasks to completed_tasks'''
    complete = input("Enter the task you want to mark complete: ").strip()
    if complete in pending_tasks:
        completed_tasks.append(pending_tasks.pop(pending_tasks.index(complete)))
    elif complete in completed_tasks:
        print("Task already completed!")
    else:
        print("Task not Found!")

#Filter by status
def filters():
    '''Let's user filter between pending tasks and completed tasks'''
    filter_task = input("Which tasks do you want to see?(Pending/Completed): ").strip().lower()
    if filter_task == "pending":
        if pending_tasks:
            print_tasks(pending_tasks)
        else:
            print("No Task Found!")
    elif filter_task == "completed":
        if completed_tasks:
            print_tasks(completed_tasks)
        else:
            print("No Task Found!")
    else:
        print("Invalid input!")

# print tasks
def print_tasks(t):
    '''prints the list of tasks to the screen'''
    for tsk in t:
        print(tsk)

#calling the main function
main()

The line that clicked hardest: completed_tasks.append(pending_tasks.pop(pending_tasks.index(complete))). That single chain finds the task by name, removes it from pending, and returns it — so it lands straight into completed_tasks. One line doing exactly the right job. That's when list methods started feeling like a real toolkit rather than a list of things to memorise.

Day 16 — List Comprehensions: Less Code, Same Power

Day 16 introduced one of Python's most beloved features — list comprehensions. Build a filtered or transformed list in a single, readable line instead of writing a full loop.

I built a number filter that splits 1–10 into even, odd, and prime — with a custom is_prime() function handling the prime logic:

def main():
    numbers = list(range(1,11))
    even_numbers = [num for num in numbers if num % 2 == 0]
    odd_numbers = [num for num in numbers if num % 2 != 0]
    prime_numbers = [num for num in numbers if is_prime(num)]
    print(even_numbers)
    print(odd_numbers)
    print(prime_numbers)


def is_prime(n):
    if n < 2:
        return False
    else:
        for i in range(2, int(pow(n, 0.5)) + 1):
            if n % i == 0:
                return False
    return True

main()

Output:

[2, 4, 6, 8, 10]
[1, 3, 5, 7, 9]
[2, 3, 5, 7]

Two things hit me at once here:

List comprehensions read like sentences: "give me every num from numbers if it's even." Once you see it, you can't unsee it — a regular for loop starts feeling like too many words.
The prime checker uses pow(n, 0.5) — the square root of n — to limit how many divisors it needs to test. That's a genuine algorithmic optimisation. Week 1 me would have looped all the way to n. Discovering that while building felt like a small unlock.

Day 17 — Dictionaries: A Contact Book

Dictionaries were the data structure I'd been reaching for since Week 1. Key-value pairs — the natural way to model real-world objects.

I built a contact book: name as the key, a nested dictionary of details as the value. Add contacts, view them, delete them:

#building a contact book
# contact -> information = mobile number, email, address
import sys
contacts = {}
app_running = True


def main():
    '''main function'''
    global app_running
    while app_running:
        print("\n\tWELCOME TO CONTACT BOOK\n")
        while True:
            ask_user = input('''What would you like to do?\n
                            (Choose the corresponding number of the task you want to perform)\n
                            1. Add/Save new contact\n
                            2. View contacts\n
                            3. Delete contact\n
                            (press 'q' to quit)\n -> ''').strip().lower()
            if ask_user == "1" or ask_user == "2" or ask_user == "3" or ask_user == "q":
                break

        match ask_user:
            case "1":
                save_contact()
            case "2":
                show_contacts()
            case "3":
                delete_contact()
            case "q":
                sys.exit()


def save_contact():
    '''Saves user's contact'''
    global app_running
    while app_running:
        if not app_running:
            break
        name = input("Enter name: ")
        user = {}
        contacts[name] = user
        while True:
            while True:
                user["mob"] = input("Enter Mobile No.: ").strip()
                user["email"] = input("Enter email: ").strip()
                if user["mob"].isdecimal():
                    break
                else:
                    print("Invalid Mobile No.")

                if "@" in user["email"]:
                    break
                else:
                    print("Invalid email!")
            user["add"] = input("Enter address: ").strip()   
            print("Contact saved...\n")
            show_contacts()
            break
        while True:
            response = input("Do you want to save another contact?(yes/no)? ")
            if response == "yes" or response == "no":
                break
        if response == "no":
           break


def show_contacts():
    '''Shows contact's of the user'''
    if contacts:
        print_contact()
    else:
        print("No Contacts found!")

def delete_contact():
    '''Deletes a contact'''
    show_contacts()
    delete = input("Enter the name of the you want to delete: ")
    if delete in contacts:
        del contacts[delete]
    else:
        print("No contact found!")


def print_contact():
    '''prints contacts'''
    for contact, user_info in contacts.items():
        print(f"Contact name: {contact}\nPhone No.: {user_info['mob']}\nEmail: {user_info['email']}\nAddress: {user_info['add']}\n")


#Calling the main function
main()

The structure that made this work: contacts[name] = user where user is itself a dictionary of mob, email, and add. That's a dictionary inside a dictionary — my first proper nested data structure, and it arrived naturally because the problem required it.

.items() in print_contact() was also new — iterating over both keys and values simultaneously instead of just one. Once you know it exists, you can't stop using it.

Day 18 — Nested Data: An Inventory System

The contact book was one level of nesting. Day 18 went three levels deep: category → item → details:

#Building an inventory system
#category-> item-> details
global price
inventory = {
    "Electronics": {
        "Laptop": {"quantity": 10, "price": 999.99, "supplier": "TechCorp"},
        "Mouse":  {"quantity": 50, "price": 25.50,  "supplier": "GadgetInc"}
    },
    "Furniture": {
        "Chair": {"quantity": 20, "price": 150.00, "supplier": "ComfortCo"}
    }
}


def main():
    cat = input("Enter the category you want the total value of (furniture/electronics): ").title()
    total_value(inventory[cat])

def total_value(inventory_item):
    products = {}
    products = inventory_item
    total = 0
    for product_info in products.values():
        total += product_info["quantity"] * product_info["price"]
    print(total)


main()

Ask for Electronics: (10 × 999.99) + (50 × 25.50) = 11,274.90.
Ask for Furniture: 20 × 150.00 = 3,000.00.

What struck me: I spent more time thinking about how to structure the dictionary than writing the functions. The shape of the data determined the shape of the code. That shift — designing data first, then writing logic around it — felt like a genuinely new layer of thinking.

Day 19 — Sets & Tuples

Day 19 was the two data structures I hadn't touched yet.

Tuples — like lists, but immutable. Once created, they can't be changed. Perfect for data that must stay fixed: config values, coordinates, question banks. The quiz project on Day 20 stores all questions and answers as tuples for exactly this reason — nothing can accidentally overwrite them mid-run.

Sets — unordered collections with no duplicates. The killer use case: deduplication. Have a list and want only the unique values? Convert to a set. Sets also have significantly faster membership checks than lists for large collections.

The mental model I settled on by end of day:

Need order + mutability? → List
Need key-value lookup? → Dictionary
Need immutable, fixed data? → Tuple
Need uniqueness + fast lookup? → Set

Day 20 — The Week 3 Project: A Python Quiz App

The end-of-week project brought together everything from the week — dictionaries, tuples, file I/O, try/except, randomisation, and a proper multi-file structure. The most architecturally considered thing I've built.

Two files: qdata.py holds all the quiz data, quiz.py runs the game.

`qdata.py` — The Data Layer

questions = (
    "How many parameters does a print statement have?",
    "Which functions returns the ASCII number associated with a char?",
    "What does the method dict.keys() return?",
    "What is the  difference between a list and a tuple?",
    "What is the full form of json?",
    "What does the function json.dumps() does?",
    "What does the function json.loads() does?",
    "In a dictionary, what does (dict_name['key']) this syntax return?",
    "Methods and functions are the same.",
    "What type of datatype does the input() function return?",
)

answers = (
    "3",
    "ord()",
    "view object",
    "A list can be modified but a tuple cannot be modified",
    "Javascript Object Notation",
    "Converts dictionary to a str",
    "Converts str to a dictionary",
    "Returns the value associated with the given key",
    "False",
    "str",
)

qna = {}
for i in range(len(questions)):
    qna[questions[i]] = answers[i]

options = [
    ["1", "2", "3", "4"],
    ["list()", "chr()", "ord()", "int()"],
    ["tuple of keys", "list of keys", "view object", "object"],
    ["They are both the same", "A list can be modified but a tuple cannot be modified", "A tuple can be modified but a list cannot be modified", "We can access an element in lists but not in tuples"],
    ["Java Subject Object Notes", "Javascript Object Notation", "Jackle and Son Oxygen Needs", "Java SON"],
    ["Closes the file", "Converts str to a dictionary", "Converts dictionary to a str", "Clears the file"],
    ["Creates a new file", "Converts dictionary to a str", "Converts str to a dictionary", "Opens the file"],
    ["Returns the key", "Returns the value associated with the given key", "Returns all the keys", "Returns the dictionary name"],
    ["True", "False", "Both True and False", "None of the above"],
    ["float", "integer", "character", "str"]
]

markers = ["A", "B", "C", "D"]

Questions and answers are tuples — immutable, so nothing can accidentally overwrite them at runtime. The qna dictionary maps each question directly to its correct answer, built dynamically with a for loop. Clean and easy to extend — add a question to questions, an answer to answers, options to options, and the game picks it up automatically.

`quiz.py` — The Game Engine

from pathlib import Path
import random
import qdata
import sys

global val
global score
num = list(range(0, 10))
file = Path("score.txt")

def main():
    while True:
        ask_user = input("Wanna play the fun python quiz?(yes/no) ").strip().lower()
        if ask_user == "yes" or ask_user == "no":
            break
    if ask_user == "yes":
        while True:
            score = 0
            random.shuffle(num)
            for n in num:
                val = n
                marked_options = dict(zip(qdata.markers, qdata.options[val]))
                display_question(val)
                display_option(marked_options)
                score = user_choice(val, score, marked_options)
            high_score(score)
            while True:
                usr = input("Wanna play again(yes/no)? ").strip().lower()
                if usr == "yes" or usr == "no":
                    break
            if usr == "no":
                sys.exit()
    else:
        sys.exit()


def display_question(val):
    print(qdata.questions[val])

def display_option(marked_options):
    for marker,option in marked_options.items():
        print(f"{marker}. {option}")

def user_choice(val, score, marked_options):
    while True:
        try:
            user_ans = input("Choose your option: ").strip().upper()
            if marked_options[user_ans] == qdata.qna[qdata.questions[val]]:
                score += 4
                print("You got it right!")
            else:
                score -= 1
                print("You are wrong:(")
            print(f"Current Score: {score}")
            return score
        except KeyError:
            print("Choose A/ B/ C/ D!!")

def high_score(score):
    h_score = 0
    if h_score < score:
        h_score = score
        file.write_text(f"High score: {h_score}")
        print(file.read_text())
    else:
        file.write_text(f"High scores: {h_score}")

main()

Everything I've learned in three weeks lives inside this project:

Tuples for immutable question and answer data
Dictionaries for the qna lookup table and marked_options per question
random.shuffle() so questions arrive in a different order every game
dict(zip()) to pair A/B/C/D markers to options on the fly
try/except KeyError to catch invalid answers gracefully instead of crashing
pathlib + file I/O to persist the high score between sessions
Multi-file structure — quiz.py imports qdata as a module, keeping data and logic completely separate

My current high score saved to score.txt: 35.

📁 What I Built This Week

Project	File	Concepts Used
To-Do List App	`todo_list.py`	Lists, `append`, `remove`, `pop`, `index`, filtering
Number Filter	`number_filter.py`	List comprehensions, prime algorithm, `pow()`
Contact Book	`contact.py`	Dictionaries, nested dicts, `.items()`, `del`
Inventory System	`inventory.py`	Nested dictionaries, `.values()`, data-first design
Python Quiz App	`python-quiz/quiz.py` + `qdata.py`	Tuples, dicts, `zip()`, `shuffle()`, `try/except`, file I/O, multi-file modules

All the code is on GitHub — every week, every file:
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

Data structures aren't just storage — they're design decisions. Choosing between a list, dictionary, tuple, or set shapes how the entire program works.
Nested dictionaries feel natural once you need them. The contact book required them. I didn't force the structure — the problem suggested it.
List comprehensions are more readable, not just shorter. [num for num in numbers if is_prime(num)] reads like a plain description of what you want.
Separating data from logic is powerful. qdata.py and quiz.py as two files meant I could change every question without touching the game engine once.
try/except KeyError is the right tool when dictionary lookups might fail on bad user input. Cleaner than checking if key in dict every time.

What I Want to Learn Next

Week 4 is on the horizon and I already know what's coming:

Object-Oriented Programming — classes and instances. The to-do app and contact book are straining against the limits of functions-and-globals. Objects feel like the natural next step.
Inheritance — sharing behaviour without copying code
__str__ and __repr__ — making objects print like real things
Larger multi-file projects — the quiz app gave me a taste of real structure

Three weeks in. The programs are starting to look like software.

If you're following along or learning Python yourself, drop your projects in the comments — beginner work deserves to be seen.

See you in Week 4. 🐍

Week 3 complete. I finally understand why everyone says "it's all about the data structures."

Week 2: From Sphaghetti to Functions

Om Kolhapure — Sun, 17 May 2026 11:12:16 +0000

Week 1 was about getting things to work.

Week 2 was about getting things to work properly.

The difference is bigger than I expected. I spent six days going back to code I was already proud of and realising it could be cleaner, safer, and smarter. Functions, error handling, built-in modules, file I/O — this week the pieces stopped feeling like separate topics and started feeling like a toolkit.

Here's what happened.

Day 8 — Functions: One Job, One Function

The rule I was given for Day 8: every function does ONE thing.

That sounds obvious until you look at your old code and realise every function you wrote does about four things. I went back to the adventure game from Week 1 and refactored it properly — breaking out start_game(), print_story(), print_location(), move_player(), beast(), check_up(), pick_up(), and game_end() into eight focused functions.

But the real lesson hit me when I built the tip calculator from scratch with clean separation from the start:

def main():
    #Ask user to input bill, tip, people
    bill = input("Enter total bill: ").strip()
    tip = input("How much tip would you like to give?: ").strip()
    people = input("Enter number of people: ").strip()
    per_person = calculate(bill, tip, people)
    print(f"Each person must cobntribute {per_person}$.")

def calculate(bill, tip, people):
    #Convert from str to int and calculate the split
    if "$" in bill:
        bill = bill.removesuffix("$")
    bill = float(bill)
    if "%" in tip:
        tip = tip.removesuffix("%")
    tip = int(tip) / 100
    people = int(people)
    return round((bill + (bill * tip)) / people, 2)

main()

main() talks to the user. calculate() does the math. Neither steps on the other's toes.

Two things I didn't expect to love here: removesuffix() — so you can type "$42" or just "42" and it handles both — and how clean return makes functions feel. You hand it data, it hands you an answer. No side effects, no surprises.

Day 9 — Parameters & Return Values

Day 9 was about really understanding what flows into and out of functions. The tip calculator covered this well — calculate() takes three parameters, does one job, and returns one value.

What clicked: functions are just machines. You feed them inputs, they produce an output. Once I started thinking that way, writing them felt much more intentional. Every parameter has a purpose. Every return value means something.

I spent extra time making calculate() handle edge cases:

What if someone types $42 with a dollar sign? → removesuffix("$") strips it
What if they type 15% instead of 15? → removesuffix("%") strips that too
Division by zero for people? → int(people) would be 0 and the function would crash — something I noted to fix with error handling later

This kind of thinking — what could go wrong? — is new for me. Week 1 me just hoped the user typed the right thing.

Day 10 — Scope & Modules

Day 10 was scope — understanding what variables live where — and modules, which is how Python lets you split code across files.

The adventure game got its cleanest version yet. Better input validation was added so the game no longer silently accepts invalid room names:

def move_player():
    global player_location
    while True:
        go = input("\nWhere would you like to go?\nbedroom\nkitchen\nliving room\n\n ")
        if go not in locations:
            print("Invalid location please choose from the list")
        if player_location == go:
            print(f"Already in {player_location}")
        else:
            player_location = go
            print_location()
            beast()
            if not game_state:
                break
            check_up()
            break

The retry logic in beast() also got cleaner:

def beast():
    global player_location
    global game_state
    beast_location = random.choice(locations)
    if beast_location == player_location:
        print("you are Dead")
        retry_input = input("Would you like to play again?(yes/no) ")
        if retry_input != "yes":
            game_state = False
        player_location = "bedroom"
    else:
        print("growlssss.........The beast is nearby")

The big scope lesson: global variables are a trade-off. They're convenient for a small game, but they make bigger programs hard to reason about. I'm already starting to see why Week 3 will probably involve classes.

Day 11 — Error Handling: `try/except`

This was one of my favourite days. Before try/except, my programs crashed the moment a user did something unexpected. After it, they handle the unexpected and keep running.

I built a days-until calculator — it tells you how many days until any date you enter:

from datetime import date
#Take input from user for target
while True:
    try:
        user_input = input("Enter you target date in (dd/mm/yyyy): ")
        day, month, year = user_input.split("/")
        day = int(day)
        month = int(month)
        year = int(year)
    except ValueError:
        print("Enter the date, month, year in dd/mm/yyyy format")
    else:
        break


target = date(year, month, day)
now = date.today()
days_until = target - now
print(f"There are {days_until.days} days until {user_input}")

Three things that clicked here at once:

try/except ValueError catches the crash when the user types something that can't be split or converted to int — instead of crashing, it loops and asks again
else on a try block — I didn't know this existed. It runs only if no exception was raised. Perfect for the break that exits the loop
from datetime import date — my first real standard library module. date.today() and date arithmetic (target - now) feel almost magical

Type "christmas" into my program and it says "Enter the date, month, year in dd/mm/yyyy format."
Week 1 me's program would have thrown a wall of red text.

Day 12 — Built-in Libraries: `random`, `datetime`, `sys`

Day 12 was about getting comfortable with Python's standard library. I built a dice roller that tracks your roll history and lets you view it mid-session:

from random import randint
import sys


previous_values = []
global value


def roll():
    '''Checks the user input and then rolls the dice and stores the value in history'''
    while True:
        while True:
            roll_dice = input("Roll the dice?(yes/ no) [press h to view history] ").strip().lower()
            if roll_dice == "yes" or roll_dice == "no" or roll_dice == "h":
                break
        if roll_dice == "no":
            sys.exit()
        elif roll_dice == "h":
            if previous_values:
                check_history()
            else:
                print("There is no history")
        else:
            value = randint(1, 6)
            print(value)
            history(value)


def history(store):
    previous_values.append(store)


def check_history():
    print(previous_values)

#Calling the roll function
roll()

New things that appeared this week:

Docstrings — '''Checks the user input...''' right under the function definition. First time I've written proper in-code documentation
sys.exit() — a clean way to quit a program from inside a function, without needing a flag variable
from random import randint — importing just the function I need instead of the whole module

Three focused functions, clear responsibilities, history that persists through the session. This felt like real program design, not just scripts.

Day 13 — The Week 2 Project: A Password Manager

The end-of-week project brought everything together: functions, file I/O, modules, error handling, and a Caesar cipher for encryption. This is the most complex thing I've built so far.

Features:

🔐 Store passwords encrypted to a file
🔍 Retrieve and decrypt them by site name
📁 Persists between sessions using json + pathlib
🔑 Caesar cipher encryption on every stored password

from pathlib import Path
import json
import random
import sys

global file
global key
key = random.randint(3, 25)
file = Path("passwords.txt")
usr_data = {}


#Take command from the user
def command():

    while True:
        com = input("Enter command(store/retrive/'q' to quit): ").strip().lower()
        if com == "store" or com == "retrive" or com == "q":
            break

    if com == "store":
        password_site()
    elif com == "retrive":
        retrive_password()
    else:
        sys.exit()

#Store the password
def password_site():
    while True:
        site_name = input("Enter site name: ")
        passwrd = input("Enter password: ").lower()
        usr_data[site_name] = cipher(passwrd, key)
        while True:
            retry = input("Do you want to store a new password(yes/no)? ").lower()
            if retry == "yes" or retry == "no":
                break
        if retry == "no":
            file.write_text(json.dumps(usr_data, indent = 4))
            print("Saved to file..")
            return

#retrive the password
def retrive_password():
    contents = json.loads(file.read_text())
    site = input("Enter site name to retrive your password: ")
    if site in contents:
       usr_password = decrypt(contents[site], key)
       print(f"Your password for {site} is {usr_password}")
    else:
        print(f"Not found site name: {site}")

#Encrypting the password using ceasar cipher
def cipher(strng, k):
    new_strng = ""
    for char in strng:
        if char.isalpha():
            if char.islower():
                c_num = ((ord(char) - ord("a")) % 26) + ord("a")
                new_strng += chr(c_num)
            elif char.isupper():
                ch_num = ((ord(char) - ord("A")) % 26) + ord("A")
                new_strng += chr(ch_num)
        else:
            new_strng += char
    return new_strng

#Decrypting the password 
def decrypt(pss, k):
    new_pss = ""
    for char in pss:
        if char.isalpha():
            if char.islower():
                char_num = ((ord(char) - ord("a")) % 26) - ord("a")
                new_pss += chr(char_num)
            elif char.isupper():
                chr_num = ((ord(char) - ord("A")) % 26) - ord("A")
                new_pss += chr(chr_num)
        else:
            new_pss += char
    return new_pss

command()

This week's project felt different from last week's. The adventure game was fun. This one felt useful. Real file persistence, real encryption logic, real user commands. I stored a password, closed the program, reopened it, retrieved the password — and it worked. That moment hit differently.

📁 What I Built This Week

Project	File	Concepts Used
Tip Calculator	`tip.py`	Functions, parameters, return values, `removesuffix()`
Days-Until Calculator	`days_until.py`	`try/except`, `datetime`, date arithmetic
Dice Roller with History	`dice.py`	`random`, `sys`, docstrings, list history
Password Manager	`passwords_manager.py`	File I/O, `json`, `pathlib`, Caesar cipher, all of the above
Adventure Game (refactored)	`game.py`	Scope, input validation, cleaner function design

All the code is on GitHub — Week 1 and Week 2, every file:
👉 github.com/Omk4314/progress-on-python

What Actually Clicked This Week

One function, one job. Once I started following this rule, my code became easier to read, easier to fix, and easier to build on.
try/except changes everything. Programs that handle bad input gracefully feel professional, not just functional.
The standard library is enormous. datetime, random, pathlib, json, sys — all built in, nothing to install. I've barely scratched the surface.
File I/O makes programs feel real. The moment my password manager wrote to a file and read it back, it stopped feeling like a script and started feeling like software.
Refactoring is a skill. Going back to Week 1 code and improving it wasn't boring — it was genuinely satisfying.

What I Want to Learn Next

Week 3 is going to push further:

Classes and OOP — I can feel the limits of global variables and I think objects are the answer
More on file I/O — reading CSVs, writing logs
Bigger projects — something that ties multiple files together properly
Maybe some APIs — pulling real data into Python feels like the next unlock

If you're following along or learning Python yourself, drop a comment — I'd love to see what you're building too.

See you in Week 3. 🐍

Two weeks in. The programs are getting real. So is the learning.

What I learned in Week 1

Om Kolhapure — Sun, 10 May 2026 11:00:10 +0000

What I Learned in Week 1 of Python — And Why I'm Already Hooked

I've been saying "I'll learn to code" for two years.

Last Monday, I actually did something about it.

No bootcamp, no cohort — just Python, VS Code, and a stubbornly blank terminal staring back at me. Seven days later, I've built a calculator, a number guessing game with difficulty levels, a password validator, a multiplication table generator, and a full text-based adventure game with rooms, inventory, and a win condition.

This is what Week 1 actually looked like.

Day 1 — Hello, World (and Hello, `print()`)

Before writing a single line of Python, I spent way too long on setup — installing Python 3.12, VS Code, the Python extension, figuring out why the terminal wasn't running my file. The setup tax is real.

But once I got there, I didn't just write one print() and move on. I explored every way Python can greet someone:

#My first python code
print("Hello, World")
#Making a greeter!!
#Ask user for his/her name
name = input("What's your name? ")
#methods to display the greeting on the screen as hello, name(whatever the name might be)
#explicitly mentioning value of end in print function
print("Hello, ", end = " ")
print(name)
#Giving two arguments to the print function
print("Hello,", name)
#Concatening Strings
print("Hello, " + name)
#Using f-strings
print(f"Hello, {name}") #The most commonly used one

That last one — the f-string — immediately became my favourite. It reads almost like writing a sentence with blanks. I didn't expect Python to feel this close to plain English on day one.

Day 2 — String Methods and the Beauty of Built-ins

Day two was variables, data types, and getting comfortable with what Python can do to strings out of the box. I wrote a small methods playground:

word = "library"
print(word.strip())      #Strips all the white spaces from left and right side of a str
print(word.capitalize()) #Capitalizes only first letter of the first word
print(word.title())      #Capitalizes first letter of every word
print(word.split()) #spits the word at whitespaces and returns an array of substring
print(word.split("r")) #splits the word at every r it will encounter 
print(word.split("r", 1)) #splits the word from the first r it encounters

#The above methods can also be written in the following way
print(word.split().title().split("r", 1))

What surprised me: how many useful things are just built into the language. No imports, no setup — just word.something() and it works. Coming from zero experience, that felt like a generous head start.

Day 3 — User Input + My First Real Program

This was the day things started feeling real. I built a calculator — and pushed it further by adding input validation so the program doesn't crash on bad data:

#Asking for input from user
x = input("What's x? ")
y = input("What's y? ")
#Check if the user's input is a digit
if x.isdecimal() and y.isdecimal() :
    x = int(x)
    y = int(y)
    #Display arthematic opreations on the screen
    print(x + y) 
    print(x - y)
    print(x * y)
    if y == 0 :
        print("Cannot divide by zero")
    else:
        print(x / y)
else:
    print("Invalid input!!")

The isdecimal() check came from Googling "how do I stop Python from crashing when someone types letters." That one search taught me more than an hour of reading would have.

Tiny win: Handling division by zero before Python could throw an error felt like writing my first real defensive code.

Day 4 — Conditionals and a Game With Difficulty Levels

if, elif, else. The traffic lights of programming.

I built a number guessing game — and pushed it further by adding difficulty levels and Python's match statement, which I stumbled onto and immediately loved:

import random

#declaring game state variable 
gameRunning = True

#Ask the user for difficulty and then set the range according to the difficulty selected
difficulty = input("Choose difficulty:\n\tEasy\n\tMedium\n\tHard\n").title()
x = 1
match difficulty:
    case "Easy":
          y = 100
    case "Medium":
         y = 500
    case "Hard":
         y = 1000
    case _:
        print("Invalid input: Please select from the given choices!")

#Generating random number and storing it in a variable
randomNumber = random.randint(x, y)
#Asking the user for input of the number
number = int(input("What's the number I am thinking about?: "))
#Tracking attempt's taken by user to guess the number
attempt = 1

while gameRunning == True:
    if number == randomNumber:
        print("Correct, you got me!")
        gameRunning = False
    elif number > randomNumber:
        print("too high")
        number = int(input("Guess Again: "))
        attempt += 1
    else:
        print("too low")
        number = int(input("Guess Again: "))
        attempt += 1
print(f"You took {attempt} attempts to guess the number!")

I played Hard mode probably ten times before moving on. When you build something fun, the learning sticks.

Day 5 — Loops: Two Programs, One Concept

Loops were the first concept that made me genuinely pause. for clicked fast. while required me to think differently — "keep doing this until something is true."

I built two programs to drill both.

Multiplication Table Generator

#setting an active flag
active = True
#Using while to run the generator as long as the user wants
while active:
    #Take input from the user
    #check if it is positive if not prompt the user Again
    while True:
        number = int(input("\nEnter a number: "))
        if number > 0:
            break
    #Using for loop iterate generate the multiplication table
    print()
    for i in range(10):
        print(f"{number} * {i + 1} = {number * (i + 1)}")
    print()
    #Asking the user if he wants to continue??
    repeat = input("Do you want to enter another number(yes/no)? ").lower()
    if repeat == "no":
        active = False

Password Validator

#Adding a error1, erro2, erro3 variables to make the code readable
error1 = "\nThe password must atleast be 8 characters long"
error2 = "The password must contain atleast an uppercase letter and it must be alphanumeric"
#print the criteria and check if the given password meets the criteria
print("The following is the criteria for a Strong password:")
print(f"{error1}\n{error2}")
while True:
    password = input("\nEnter your password: ")
    #The password should be 8 characters long
    # it should have a uppercase letter and it should be alphanumeric
    if len(password) >= 8 and any(char.isupper() for char in password) and any(char.isdecimal() for char in password):
        print("\nCongrats!, it's a strong password")
        print()
        break
    else:
        print(error1,error2, sep = "\n")
        print()

The any() function was a side-discovery here — found it while looking for a clean way to scan every character in a string. Those little finds while building are my favourite part of self-learning.

Day 6 & 7 — The Project: A Text-Based Adventure Game

The end-of-week project was the most fun I've had coding so far. I built a full game called The Abandoned House:

🗺️ Three rooms to explore (bedroom, kitchen, living room)
🎒 An inventory system — flashlight in the bedroom, key in the kitchen
👹 A random beast that kills you if it appears in your room
🏆 A real win condition — collect both items, reach the living room
🔁 A retry option when you die

Here's the full code:

import random
#set gamestate
game_state = True
#player location
player_location = "bedroom"
#Adding tools
tools = {"bedroom": "flashlight", "kitchen": "key"}
inventory = []
#Adding locations
locations = ["bedroom", "kitchen", "living room"]

def main():
    start_game()
    if not game_state:
        return
    print_story()
    while game_state:
        #location printing
        #check for items 
        #pickup if there
        # where to?
        if not game_state:
            break
        print_location()
        move_player()
        if not game_state:
            break
        game_end()

def start_game():
    global game_state
    game_menu = input("\n\tThe Abondoned House\n\n\tStart\n\tQuit\n\n").title()
    if game_menu == "Quit":
        print("\nQuitting....")
        game_state = False
    else:
        print("\nLoading...")

def print_story():
    print('''\nIt's midnight, I am driving on a narrow road in the middle of a forest; Oh shit
I just hit something. (opens the car door and steps out looks behind, but sees
no one confused as he turns back to get into his car) Ahhh..... (Get hits by 
someone in the head and becomes unconcious After a while...) Where am I??(Wakes up in a room)
, I have to get out of here!")''')
    return

def print_location():
    global player_location
    print(f"\nI'm in the {player_location}")

def move_player():
    global player_location
    while True:
        go = input("\nWhere would you like to go?\nbedroom\nkitchen\nliving room\n\n ")
        if player_location == go:
            print(f"Already in {player_location}")
        else:
            player_location = go
            print_location()
            beast()
            if not game_state:
                break
            check_up()
            break

def beast():
    global player_location
    global game_state
    beast_location = random.choice(locations)
    if beast_location == player_location:
        print("you are Dead")
        retry_input = input("Would you like to play again?(yes/no) ")
        if retry_input == "yes":
            move_player()
        else:
            game_state = False
    else:
        print("growlssss.........The beast is nearby")

def check_up():
    global player_location
    if player_location in tools:
        pick_up()
    else:
        print("There is nothing useful here!")

def pick_up():
    pick = input(f"Would you like to pickup {tools[player_location]}?(yes/no)? ")
    if pick == "yes":
        print("Picking up...")
        inventory.append(tools.pop(player_location))
        print(f"inventory updated: {inventory}")
    else:
        game_end()

def game_end():
    global player_location
    global game_state
    if "flashlight" in inventory and "key" in inventory and player_location == "living room":
        print("I am finally out of this house!")
        game_state = False
    else:
        print("I am missing one more thing!")
        move_player()

main()

The moment the win condition triggered for the first time — "I am finally out of this house!" — felt like a genuine milestone. This wasn't a tutorial I followed. I built this.

📁 What I Built This Week

Project	File	Concepts Used
Hello World + Greeter	`hello.py`	`print()`, `input()`, f-strings
String Methods Playground	`methods.py`	String methods, data types
Calculator	`calculator.py`	`input()`, `if/elif/else`, `isdecimal()`
Number Guessing Game	`guessTheNumber.py`	`while`, `random`, `match`, conditionals
Multiplication Table	`table.py`	`for` loop, nested `while`
Password Validator	`password.py`	`while`, `any()`, string methods
Text Adventure Game	`game.py`	Functions, global state, everything above

All the code is on GitHub — every file, every day:
👉 github.com/Omk4314/progress-on-python

I'm committing daily — even the messy days.

What Actually Clicked This Week

Python reads like English. I expected gibberish. I got readable logic.
Building > drilling. The calculator taught me more than ten isolated exercises ever could.
Errors are clues. Once I stopped panicking at red text, debugging became a puzzle, not a crisis.
match is underrated. I stumbled onto it and immediately liked it more than long if/elif chains.
Momentum matters. Day 1 was rough. By Day 5 I was genuinely looking forward to opening the terminal.

What I Want to Learn Next

Week 2 is going to cover:

Functions properly — I've been using them without fully understanding the mechanics
Lists and dictionaries — my adventure game needed them and I can feel the gap
Basic file I/O — so my game can actually save progress
Maybe some OOP — no promises, just curiosity

If you're also learning Python from scratch, I'd love to see what you're building. Drop it in the comments — beginner projects deserve to be seen.

See you next week. 🐍

Week 1 complete. The terminal no longer scares me. That's enough for now.

DEV Community: Om Kolhapure

Week 9: Finally, I understand the Web.

Day 57 — HTML Structure: A Real Portfolio Page

Day 58 — CSS Fundamentals: Making It Actually Look Like Something

Day 59 — JavaScript Basics: A Dark Mode Toggle

Day 60 — DOM Manipulation: A Real To-Do List

Day 61 — Fetch API: Talking to a Real Server

Day 62 — Weather Dashboard: Still In Progress

📁 What I Built This Week

What Actually Clicked This Week

What I Want to Learn Next

Month 2: From OOP to Algorithms.

The Structure: Four Very Different Weeks

Week 5 — OOP Deep Dive

What I learned

What I built

The moment that clicked

Biggest surprise

Week 6 — One Project, One Week

What I learned

What I built

The moment that clicked

Biggest surprise

Week 7 — A Hard Pivot Into Algorithms

What I learned

What I built

The moment that clicked

Biggest surprise

Week 8 — Building the Structures Themselves

What I learned

What I built

The moment that clicked

Biggest surprise

Everything I Built in Month 2

What Changed in Month 2

What I'd Tell Myself at the Start of Month 2

What's Next

What I Learned in Week 8 of Python — Stacks, Queues & Linked Lists

Day 50 — Stacks: LIFO, From Scratch

Day 51 — Queues: FIFO, and Stack-via-Queue

Day 52 — Linked Lists: My First Pointer-Based Structure

Day 53 — More Linked Lists: Merging and Removing

Merge Two Sorted Lists

Remove Nth Node From End of List

Day 54 — The Week 8 Project: A Browser History Tracker

Day 55 — Review: All of Month 2, Re-Solved

📁 What I Built This Week

What Actually Clicked This Week

What I Want to Learn Next

Week 7: My First Agorithms.

Day 43 — Big O Notation: Naming the Thing I'd Been Feeling

Day 44 — Arrays & Hashing: Three Classic Problems

Two Sum

Contains Duplicate

Valid Anagram

Day 45 — More Hashing: Anagrams and Top-K

Group Anagrams

Top K Frequent Elements

Day 46 — Two Pointers: A Different Way to Walk an Array

Valid Palindrome

Two Sum II (sorted input)

3Sum

Day 47 — Sliding Window: Watching a Window Move

Best Time to Buy and Sell Stock

Longest Substring Without Repeating Characters

Day 48 — Review + Mock: Solving Without Hints, Against the Clock

📁 What I Solved This Week

What Actually Clicked This Week

What I Want to Learn Next

I Built a URL Shortener in a Week.

Day 36 — Design Before Code

Day 37 — Building the CLI: JSON Storage & Core Logic

generate_code()

shorten_url() — deduplication

store_urls() and retrieve_urls()

Day 38 — Analytics: Tracking Clicks in CSV

Day 39 — README & GitHub

Day 40 — Sharing & Getting Feedback

Day 41 — Refactoring From Feedback

📁 What I Built This Week

`generate_code()`

`shorten_url()` — deduplication

`store_urls()` and `retrieve_urls()`

`qdata.py` — The Data Layer

`quiz.py` — The Game Engine

Day 11 — Error Handling: `try/except`

Day 12 — Built-in Libraries: `random`, `datetime`, `sys`