Projects: Notes App & Expense Tracker

The Mystery of the Disappearing Data

Have you ever added items to a list inside a running Python script, only to find that every single item vanished the second the script finished running? Understanding why in-memory data disappears when your application closes is the key to building software that retains its state.

Run this code in your editor to see the reset in action:

Current notes in memory: ['Buy groceries', 'Call the bank']

Now, if you run the exact same script a second time, you might expect your previous notes to still be there. Instead, the script creates a fresh notes list from scratch, and you end up with the exact same output again:

Current notes in memory: ['Buy groceries', 'Call the bank']

Here is what is happening under the hood:

• In-Memory Storage Volatility: When your script runs, variables like notes live inside your computer's temporary memory (RAM). RAM is fast, but it is volatile, meaning all stored data is completely wiped the moment the application lifecycle ends or your program stops executing.
• Persistent File Storage: To keep data around permanently, you must write it out to disk in a persistent format like a local file (such as a .json or .csv file). Files stored on your hard drive survive program restarts, system reboots, and power cutoffs.
• Application Lifecycle State Persistence: Bridging the gap between fast temporary RAM and long-term file storage ensures your app maintains its state across multiple user sessions.

In this module, you will learn how to bridge this gap by reading and writing your application data directly to local files!

Unlocking Real Utility with Local Storage

Once your code can save and reload data between runs, you cross the threshold from writing throwaway scripts to building real, practical software. Adding local file persistence turns basic Python scripts into fully functional everyday tools like expense trackers, note-taking apps, and task managers.

The Engine of Useful Apps: CRUD

To turn a plain script into an interactive tool, your application needs a structured way to manage stored data. Virtually every practical application relies on four fundamental operations collectively known as CRUD.

When you build local tools, you will design features around these four core actions:

• Create: Adding new information to your storage file (for example, logging a new $5 coffee purchase in an expense log).
• Read: Loading and displaying saved data back to the user (for example, opening your app to view your saved notes).
• Update: Modifying existing records in your file (for example, editing an expense category or marking a task as completed).
• Delete: Removing unnecessary records permanently from your storage (for example, discarding an old reminder).

Mastering CRUD means your programs can handle data fluidly across user sessions, keeping your saved content up to date.

Choosing Your Storage Format: JSON vs. CSV

To implement CRUD effectively, you must store your data in a structure that fits your application's needs. In local Python development, you will primarily choose between two file formats: .csv and .json.

Selecting the right file format depends entirely on how complex your app's data is.

If you are tracking daily purchases with uniform fields like date, item, and cost, a .csv file offers a lightweight spreadsheet-like model. However, if you are building a notes app where a single note might contain a title, multi-line text body, a list of tags, and timestamp metadata, .json is the natural choice.

By pairing solid CRUD logic with the right file format, you give your Python projects long-term memory and true utility.

The Digital Ledger and Filing Cabinet

Before software existed, businesses and individuals managed massive amounts of information using physical tools like index cards, filing cabinets, and paper ledgers. Understanding how data files work in modern software becomes effortless when you picture them as these physical record-keeping systems.

By mapping modern data formats like JSON and CSV to physical objects, you can easily visualize how your application creates, reads, updates, and deletes data behind the scenes.

JSON Files: The Digital Box of Index Cards

Imagine you are building a digital Notes Application. In the physical world, the best tool for flexible, individual notes is a box of index cards.

Each index card represents a single note. On a physical card, you might write labeled fields such as a title, a date, a category tag, and the main body text. You can add as many cards as you want to your box, and each card holds its own detailed content neatly organized by those labels.

A .json file acts just like this box of index cards. It holds individual records grouped together, where each record uses explicit text labels to pair names with values. Here is how your standard CRUD operations map directly to managing physical index cards:

• Create: Grabbing a blank index card, writing a new note on it, and dropping it into the box.
• Read: Opening the box, pulling out a specific card, and reading the text written on it.
• Update: Taking an existing card out of the box, erasing an outdated detail, and writing the updated information.
• Delete: Finding a card you no longer need and tossing it into the trash can.

CSV Files: The Accounting Ledger

Now, imagine you are building an Expense Tracker instead of a notes app. Index cards would be messy for tracking hundreds of daily payments because you need rigid structure and clear rows. Instead, you would use a bound financial ledger book.

A paper ledger is formatted as a strict grid. The top of the page features fixed column headers: Date, Category, and Amount. Every time a financial transaction occurs, you write the details across a single horizontal line under those specific headers.

A .csv file is the digital twin of this paper ledger. It stores plain text organized into rows separated by line breaks, with values in each row separated by commas. Every line in the file corresponds to a single row in your ledger.

Here is how CRUD operations work on a physical ledger:

• Create: Moving your pen to the first empty row at the bottom of the ledger page and writing a new transaction across the columns.
• Read: Scanning your eyes down the grid to find all entries listed under the "Amount" column for a specific date.
• Update: Locating a line where you accidentally miswritten an expense amount, crossing out the incorrect number with a pen, and writing the correct value right beside it.
• Delete: Drawing a dark line through an entire row to show that the record is invalid and should no longer count toward your totals.

Comparing Physical Storage to Digital Files

To help you choose the right format for your data management tasks, let's look at how physical record-keeping translates directly to technical data structures:

By visualizing data files as physical tools, file operations stop feeling abstract. Whenever you design a storage flow, simply ask yourself: "Am I storing loose index cards in a box (JSON), or am I recording uniform rows in a ledger (CSV)?"

Building Create and Read Flows for Notes

Every persistent application needs a reliable way to initialize storage, load saved items on startup, and save new user input. In this section, you will build the foundational Create and Read workflows for a text-based notes app using a local json file.

To make your notes application work seamlessly across multiple sessions, you need to establish a three-step cycle during runtime:

• Check & Initialize: Verify if your storage file exists on launch, creating a fresh default structure if it is missing.
• Load & Render (Read): Read existing notes from disk into a Python dict so your program can process and display them.
• Append & Dump (Create): Add new note entries to your in-memory collection and save the updated dictionary back to disk.

Run this complete script to see how Python manages reading from and writing to local JSON storage:

Expected Output

When running the script for the first time, you will see output similar to this:

Created new notes.json storage file.

--- Current Stored Notes ---
[1] Grocery List: Buy milk, eggs, and sourdough bread.

The Breakdown

Let's walk through how this script operates mechanics-by-mechanics:

• Path("notes.json"): Creates a file path object targeting notes.json in your current working directory.
• if not file_path.exists():: Checks if the storage file exists yet. If it does not, we initialize a default data structure containing an empty list assigned to the key "notes".
• json.dump(initial_data, file, indent=4): Converts the Python dict into structured JSON text and writes it to disk. The indent=4 argument formats the raw text with readable spacing.
• json.load(file): Parses the raw text inside notes.json and reconstructs it into a native Python dict stored in data.
• data["notes"].append(new_note): Appends our new_note dictionary directly to the "notes" list inside our in-memory data collection. The id key dynamically updates based on the current length of the list.
• for note in updated_data["notes"]:: Iterates over every dictionary inside the "notes" list, allowing you to extract individual fields like title and content for clean user display.

Building Update and Delete Flows for Expenses

When working with plain text files like .csv files, you cannot reach directly into the middle of a file to modify a single number or delete an individual line. To modify existing data, you must master the Read-Modify-Write pattern, which gives you complete control over updating local storage safely.

Understanding the Read-Modify-Write Pattern

Since .csv files are sequential streams of text, modifying an expense record requires a distinct three-step strategy:

• Read: Load all rows from your .csv file into Python memory as a collection of dictionaries.
• Modify: Iterate through your list to update matching entries or filter out entries you want to delete.
• Write: Overwrite the original .csv file completely with your freshly modified list of entries.

Here is a quick comparison of how this pattern handles updates versus deletions:

Let's look at a complete script that creates sample expense data, updates one record, deletes another, and saves the changes back to disk.

Expected Output

When you run this code in your terminal, you will see the following output confirming that record 3 was removed and record 2 had its amount modified:

Original Data: [{'id': '1', 'category': 'Groceries', 'amount': '50.00'}, {'id': '2', 'category': 'Utilities', 'amount': '120.00'}, {'id': '3', 'category': 'Coffee', 'amount': '4.50'}]

File contents after Write phase:
id,category,amount
1,Groceries,50.00
2,Utilities,135.00

Code Breakdown

Let's break down the core steps in the code so you know exactly how each piece works:

1. Reading into memory (csv.DictReader): We open expenses.csv in read mode ("r") and use csv.DictReader to convert each row into a standard Python dictionary. We append each dictionary into our expenses list.
2. Filtering out records (Deletion): We check if expense["id"] == target_delete_id. By executing continue, we skip the entry for Coffee (id: "3"). Excluding a record while building a new list is the standard way to perform deletions in flat files.
3. Mutating records (Updating): When expense["id"] == target_update_id matches record 2, we reassign expense["amount"] = "135.00". Because dictionaries are mutable in Python, this updates the entry directly.
4. Safely Overwriting (csv.DictWriter): We open expenses.csv using write mode ("w"). Using write mode replaces the old file contents with your updated list, ensuring local file storage stays perfectly synchronized with your application's state.

The Memory-Disk Sync Loop

When your user interacts with your application, changes do not instantly appear on your hard drive. Understanding the explicit lifecycle between fast runtime memory and permanent disk storage is the key to preventing lost data and broken state.

Think of runtime memory (RAM) as your active whiteboard and disk storage as your filing cabinet. You do all your fast, dirty edits on the whiteboard while the app is running. However, if someone pulls the power plug, the whiteboard gets wiped clean unless you explicitly copy those changes back into the filing cabinet.

Comparing In-Memory Mutation vs. Disk Synchronization

Before looking at the code, let's contrast how your application treats data when it lives in RAM versus when it is saved to disk:

To manage this safely, your application follows a strict three-step loop: - Load: Read file data from disk into Python memory when the program starts. - Mutate: Update, append, or delete records inside Python data structures (lists or dicts) during user interactions. - Sync: Serialize the modified memory structure and write it back out to the file system.

Let's see this full lifecycle in action. Run this Python code to see how memory changes compare to disk state:

Output

When you run this script in your terminal, you will see the explicit progression from memory manipulation to disk persistence:

1. RAM state after load: [{'id': 1, 'text': 'Buy groceries'}]
2. RAM state after mutation: [{'id': 1, 'text': 'Buy groceries'}, {'id': 2, 'text': 'Schedule dentist appointment'}]
3. Disk state after sync: [{'id': 1, 'text': 'Buy groceries'}, {'id': 2, 'text': 'Schedule dentist appointment'}]

The Breakdown

Here is what happens behind the scenes during each phase of the sync loop:

• json.load(f): Reads the raw text from user_notes.json on your hard drive, parses the text structure, and converts it into native Python objects stored in the ram_notes variable.
• ram_notes.append(new_note): Performs an in-memory mutation. You are altering the list object residing in active RAM. At this exact millisecond, user_notes.json on disk still only contains the original single note.
• open(file_path, "w"): Opens a file handle in write mode. This action empties the existing file on disk so it is ready to accept brand-new content.
• json.dump(ram_notes, f, indent=2): Performs disk synchronization. It converts your updated ram_notes list back into a formatted string and writes those bytes directly to your disk, bringing memory and disk back into perfect alignment.

Mastering File-Based Application Architecture

You have officially mastered the fundamentals of building file-backed applications in Python! Understanding how to manage state with local files allows you to persist data across user sessions without relying on complex external systems.

The Complete File-Based CRUD Pipeline

Throughout this module, you implemented a complete CRUD (Create, Read, Update, Delete) workflow powered by the memory-disk sync loop. Every operation follows a predictable lifecycle:

• Create: Read existing data from disk, append your new item to the in-memory list or dict, and write the full structure back to disk.
• Read: Open the stored .json or .csv file, parse raw text into native Python objects, and present the data to the user.
• Update: Load the file into memory, find and mutate the target record, and save the updated data structure back to disk.
• Delete: Read the saved data, filter out the unwanted item using Python operations, and overwrite the file with the remaining entries.

Local File Storage: JSON vs. CSV

Choosing the right format for local persistence comes down to the structure of your data. Here is how local .json and .csv persistence stack up against each other:

What's Next?

Now that your data sync pipeline is solid, think about what happens when something unexpected occurs like a missing file or corrupted syntax. Your next major milestone will be adding defensive error handling to make your file pipelines completely crash-proof.