DEV Community: Nattar Kani Murugan

Day 4: Building a Library Management System with Python OOP | 10 Weeks Challenge | To AI Engineer

Nattar Kani Murugan — Sat, 22 Aug 2026 19:49:22 +0000

Okay, Nattar.

The challenge today was:

Model a library-management system with 6+ classes, ABCs and dataclasses. It must pass mypy clean.

This one felt different from the previous three days.

Day 1: Text Analyzer.

Day 2: Comprehensions + generators.

Day 3: Decorators + my own Python package.

Today, I had to stop thinking only about individual functions and start thinking about:

Objects.

Relationships.

Responsibilities.

And honestly...

my brain had a few moments of:

First, I needed a map

Before creating classes, I wanted to understand what actually exists inside a library management system.

So I created a mind map of the overall architecture and features.

Library Management System
│
├── Library
│ ├── Items
│ ├── Members
│ └── Loans
│
├── Library Items
│ ├── Book
│ ├── Magazine
│ ├── Newspaper
│ └── DVD
│
├── People
│ ├── Member
│ └── Author
│
├── Borrowing
│ ├── Borrow
│ └── Return
│
└── Abstractions
├── LibraryItem
└── Borrowable

Step 1: Start with abstraction

I created an abstract base class for library items.

from abc import ABC, abstractmethod

class LibraryItem(ABC):

    @abstractmethod
    def description(self) -> str:
        pass

The idea is simple.

Every library item should be able to describe itself.

A book can describe itself. A magazine can describe itself. A newspaper can describe itself. A DVD can describe itself.

But LibraryItem itself doesn't need to know exactly how. That's where abstraction comes in.

Step 2: What can actually be borrowed?

Then I created another abstraction:

class Borrowable(ABC):

    @abstractmethod
    def borrow(self) -> None:
        pass

    @abstractmethod
    def return_item(self) -> None:
        pass

This was an interesting distinction. Not every library item necessarily needs to be borrowable.

For example, I could have:

Book       → Borrowable
DVD        → Borrowable
Magazine   → Maybe not
Newspaper  → Maybe not

So instead of putting borrow() directly into every library item, I created a separate abstraction for borrowable behaviour.

Step 3: Creating the actual items

@dataclass
class Book(LibraryItem, BorrowableItem):
    title: str
    isbn: str
    author: Author
    _available: bool = True

    def description(self) -> str:
        return f"{self.title} by {self.author}"

A Book is:

A LibraryItem
A BorrowableItem

This was my first hands-on experience with multiple inheritance in this project.

Wait... why multiple inheritance?

This was one of those moments where I had to stop and think. A book is a library item. But a book also has the behaviour of something that can be borrowed.

So I modelled that relationship as:

Book
├── LibraryItem
└── BorrowableItem

The interesting part is that BorrowableItem itself implements the actual borrowing behaviour.

class BorrowableItem(Borrowable):

    _available: bool

    @property
    def available(self) -> bool:
        return self._available

    @available.setter
    def available(self, value: bool) -> None:
        if not isinstance(value, bool):
            raise TypeError(
                "You are not allowed to change this"
            )

        self._available = value

    def borrow(self) -> None:
        if not self.available:
            raise ValueError("Item not available")

        self.available = False

    def return_item(self) -> None:
        self.available = True

Now the borrowing logic doesn't need to be repeated inside Book and DVD.

Step 4: DVD can use the same behaviour

A DVD can also be borrowed.

@dataclass
class DVD(LibraryItem, BorrowableItem):
    title: str
    duration: int
    _available: bool = True

    def description(self) -> str:
        return f"{self.title} runtime is {self.duration}"

The DVD doesn't need to implement borrow() and return_item() again. It gets that behaviour from BorrowableItem. This was a good reminder that inheritance isn't only about sharing data.

It can also be about sharing behaviour.

Step 5: Not everything needs borrowing

I also created classes for things like magazines and newspapers.

For example:

@dataclass
class Magazine(LibraryItem):
    title: str
    edition: int

    def description(self) -> str:
        return f"Magazine {self.title} of edition {self.edition}"

And:

@dataclass
class Newspaper(LibraryItem):
    title: str
    date: date

    def description(self) -> str:
        return f"{self.title} newspaper issued on {self.date}"

Notice something?

They inherit from LibraryItem. But not BorrowableItem. That was intentional.

Step 6: Dataclasses saved me from boilerplate

I used @dataclass quite heavily.

For example:

@dataclass
class Author:
    name: str
    birth_year: int

And:

@dataclass
class Member:
    member_id: int
    name: str
    borrowed_items: list[Borrowable] = field(default_factory=list)

Instead of manually writing constructors for every class, dataclasses generate a lot of that boilerplate for me.

And field(default_factory=list) was particularly useful.

I don't want every Member to accidentally share the same list of borrowed items. So each member gets their own list.

Step 7: I finally used some dunder methods

I also wanted to experiment with dunder methods.

For Book, I added __str__():

def __str__(self) -> str:
    return self.description()

print(book)

can give me something meaningful instead of a default object representation.

I also experimented with __eq__().

For books, I decided that the ISBN should determine equality:

def __eq__(self, other) -> bool:
    if isinstance(other, Book):
        return self.isbn == other.isbn

    return NotImplemented

So two book objects with the same ISBN can be considered equal. That made me realise something:

Dunder methods aren't just strange methods with double underscores.

They let my objects behave more naturally with Python's built-in operations.

Step 8: Who manages everything?

Now I needed something to actually manage the library.

Enter:

@dataclass
class Library:
    items: list[LibraryItem] = field(default_factory=list)
    members: list[Member] = field(default_factory=list)
    loans: list[Loan] = field(default_factory=list)

The Library contains:

Library items
Members
Loans

This is where composition came into the picture.

A library isn't a member.

A library isn't a book.

A library has members, books and loans.

That distinction helped me understand the difference between composition and inheritance much better.

Step 9: Borrowing an item

The library can handle borrowing:

def borrow_item(
    self,
    member: Member,
    item: Borrowable
) -> None:

    if member not in self.members:
        raise ValueError("Member not registered")

    if item not in self.items:
        raise ValueError("Item is not in the library")

    member.borrow(item)

    loan = Loan(
        member=member,
        item=item,
        borrowed_date=date.today()
    )

    self.loans.append(loan)

Now there are multiple objects involved.

The:

Library

knows about the:

Member

and the:

Item

and creates a:

Loan

This is where the architecture started feeling like an actual system rather than a collection of unrelated classes.

Step 10: A loan is its own object

Instead of storing borrowing information randomly, I created a Loan class:

@dataclass
class Loan:
    member: Member
    item: Borrowable
    borrowed_date: date
    returned_date: date | None = None

    @property
    def is_active(self) -> bool:
        return self.returned_date is None

This was another useful design decision.

A loan has its own information:

Who borrowed it?
What did they borrow?
When did they borrow it?
Has it been returned?

Instead of putting all of that information into Member or Library, I gave it its own object.

And then... mypy

The challenge had one more requirement:

It must pass mypy clean.

So I had to pay attention to type hints throughout the code.

For example:

def add_item(self, item: LibraryItem) -> None:
    self.items.append(item)

And:

def borrow(
    self,
    item: Borrowable
) -> None:
    ...

And:

returned_date: date | None = None

Running:

mypy .

became part of my workflow.

And honestly, I liked this.

What did I actually learn?

Today's challenge gave me hands-on practice with:

Classes
Objects
Inheritance
Multiple inheritance
Abstraction
Abstract Base Classes
Composition
Dataclasses
field(default_factory=...)
Properties
Getters and setters
Dunder methods
__str__
__eq__
Type hints
mypy
Domain modelling

But the biggest lesson wasn't any individual Python feature.

It was this:

Before writing classes, understand the objects and relationships in the problem.

The mind map helped more than I expected

This is probably my favourite part of today's challenge.

I created the architecture mind map before or alongside the implementation.

Day 4: Done. ✅

Four days into the challenge.

And the projects are slowly getting bigger.

I'm starting to realise that learning Python isn't just about learning more syntax. It's also about learning how to model problems.

And today, I finally spent more time thinking about the design before thinking about the code. That's progress.

So...

One more day done.

Keep going, Nattar. 🚀

🔗 The project

I've added today's Library Management System to GitHub as part of my 10 Week AI Challenge.

👉 View the Library Management System on GitHub

See you on Day 5.

Day 3: Learning Decorators by Building My Own Python Library

Nattar Kani Murugan — Fri, 21 Aug 2026 19:11:12 +0000

Okay, Nattar. Day 3.

Yesterday was comprehensions and generators. Today, I went down a different Python rabbit hole: Decorators

I had seen decorators before, but seeing @something above a function and actually understanding what happens underneath are two very different things.

So instead of just reading about them, I decided to build a small decorator library.

First... what is a decorator?

The simplest way I can explain it to myself:

A decorator lets me add extra behaviour to a function without changing the original function.

For example:

@log_calls
def add(a, b):
    return a + b

The add() function still does what it was supposed to do.

The decorator simply adds something around it. And that's the idea I wanted to practice.

My five decorators

1. `log_calls`

This one logs the function name and the arguments passed to it.

def log_calls(func):

    @wraps(func)
    def wrapper(*args, **kwargs):
        print(
            f"Calling function {func.__name__} "
            f"with arguments {args} and keyword arguments {kwargs}"
        )
        result = func(*args, **kwargs)
        return result

    return wrapper

This helped me understand *args and **kwargs a little better too.

2. `timeit`

I wanted to know how long a function takes to execute.

start = time.time()

result = func(*args, **kwargs)

end = time.time()
elapsed = end - start

So instead of adding this timing logic inside every function, I can simply use:

@timeit
def my_function():
    ...

3. `retry`

What happens if a function fails?

Try again. That's what this decorator does.

for i in range(3):
    try:
        result = func(*args, **kwargs)
        return result
    except Exception as e:
        error = e
        print(f"Attempt {i+1} failed..")

If the function fails, it gets three attempts before the error is raised.

4. `cache`

This one was interesting. If I call a function with the same arguments multiple times, why calculate the same result again?

cache = {}

key = (args, tuple(kwargs.items()))

if key in cache:
    return cache[key]

result = func(*args, **kwargs)

cache[key] = result
return result

Now the result can be reused when the same arguments are passed again. This was my first hands-on experience with implementing caching rather than just hearing about it.

5. `validate`

Finally, I wanted to experiment with validating function arguments using type annotations.

I used inspect.signature() to bind the arguments and then checked their types:

expected_type = annotations.get(name)

if not isinstance(value, expected_type):
    raise TypeError(...)

So I could write something like:

@validate
def add(a: int, b: int):
    return a + b

And the decorator checks whether the arguments are actually integers before running the function.

And then I thought...

Why stop at five .py files?

I wanted to try turning these decorators into an installable Python package. So I created a package structure, added the necessary package configuration, and tried installing it locally.

Something like:

pip install .

And then I could import the decorators into another project. That was probably my favourite part of today's challenge.

What did I learn today?

Today I got hands-on with:

Decorators
Wrapper functions
@wraps
*args and **kwargs
Caching
Logging
Retry logic
Function timing
Type validation
inspect.signature()
Python package structure
Making a local package installable

Today started with: "Let's learn decorators."

And ended with: "Wait... I actually built a package."

Not bad. Still a long way to go.

But that's exactly why I started this 10 Week AI Challenge. I'm not trying to become an AI engineer in ten days. I'm trying to build the foundation that will help me become one.

Day 3: Done. ✅

Three days in. Three different learning experiences.

See you on Day 4. 🚀

I've added my decorator library to GitHub as part of my 10 Week AI Challenge.

👉 View the Decorator Library on GitHub

Keep going, Nattar.

Day 2: Comprehensions & My First Generator-Based File Reader | Python | Day 2 | Week 1 | 10 Week Challenge

Nattar Kani Murugan — Thu, 20 Aug 2026 18:48:11 +0000

Okay, Nattar.

Day 2.

Yesterday, I built a simple Text Analyzer. Today, I decided not to build another big project. Instead, I wanted to sit down and solve 25 small Python problems.

And apparently, today's main character was: Comprehensions. 😅

And then, just when I thought I was done, I got introduced to generators and yield.

So let's see what I actually learned today.

What is a comprehension?
Before today, I had seen comprehensions quite a few times. But seeing them and actually understanding them are two different things.

The simplest way I can explain it to myself is:

A comprehension is a shorter way of creating a collection by looping through something, with an option to apply a condition.

For example, the normal way of creating a list of squares would be,

numbers = [1, 2, 3, 4, 5] squares = [] for num in numbers: squares.append(num * num)

With a list comprehension, I can write,

numbers = [1, 2, 3, 4, 5] squares = [num * num for num in numbers]

Same idea. Much shorter.

At first glance, the comprehension looks a little weird. My brain wants to read it from left to right like normal code, which is probably not the best idea.

So I'm trying to get comfortable reading it as:

"For every number in numbers, give me number squared."

Comprehensions can also include conditions. For example, if I only want even numbers,

numbers = [1, 2, 3, 4, 5, 6] even_numbers = [num for num in numbers if num % 2 == 0]

Again, same logic. Just compressed into one line.

I'm definitely not going to claim that I'm a comprehension expert after one day. But I can finally look at one and understand what it is trying to do.

The main part of today's challenge was solving 25 problems based around comprehensions. I worked through different variations involving:

Lists
Numbers
Strings
Conditions
Filtering
Transforming values
List comprehensions
Set comprehensions
Dictionary comprehensions

The interesting part wasn't really the individual problems. It was seeing the same basic idea appear in different situations.

And then came generators...
I thought the comprehension part was going to be the main learning of today. Then I started working on a generator-based file reader. And this one made something click for me. Especially because I had always thought about reading a file like this:

"Open the file → load everything → work with it."

But generators introduced a different way of thinking.

I wrote a simple function.

def read_file(filename):
    with open(filename,"r") as file:
        for line in file:
            yield line

Then I created the generator.

reader = read_file("sample.txt")

And used it like this.

for line in reader:
    print(line)

That's it. But there is actually something interesting happening here.

What is yield doing?
This was the part I had to think about.

When Python reaches:

yield line

It doesn't return all the lines at once. It gives me one line and pauses the function. When I ask for the next value, it continues from where it stopped and gives me the next line.

That makes generators particularly useful when working with large amounts of data. And considering where I'm heading with data and AI...

I have a feeling this concept is going to show up again.

I learnt:

List comprehensions
Set comprehensions
Dictionary comprehensions
Conditions inside comprehensions
Transforming data while creating collections
yield
Generators
next()
Iterating through a generator
Reading files line by line
Why generators can be useful for large files

But more importantly, I learned something about how I learn Python. Sometimes I understand something when I see the code.But I really understand it when I can explain why the code behaves that way.

So...

Day 2: done. ✅

Github Repo

Text Analyzer | Python | Day 1 | Week 1| 10WeekChallenge

Nattar Kani Murugan — Wed, 19 Aug 2026 19:16:31 +0000

Okay, Nattar.

You said you wanted to get better at Python.

Not just watch another tutorial. Not just save another course. Not just tell yourself, “I'll start tomorrow.”

So... let's actually build something.

This is Week 1 of my 10 Week AI Challenge, and I decided to start with something simple: a Text Analyzer.

Nothing fancy. No Python libary. No AI model. No API. No LangChain. No vector database.

Just Python. And honestly, that is exactly what I needed.

So, what does this thing actually do?

I wanted to take some text and make Python answer a few basic questions about it.

Things like:

How many sentences are there?
How many words?
Which words appear the most?
What are the most common word combinations?
How readable is the text?

So I broke the problem into smaller pieces.

The final analyzer has a few steps:

Take text as input
Validate the input
Count sentences
Normalize and tokenize the text
Calculate word frequency
Find the top N words
Find common n-grams
Calculate a reading score

Sounds simple. And that's the point.

Step 1: Okay, give me some text

Python needs something to work with. So I started with basic input handling.

text = input('Enter your text: ')

Step 2: But what if I give it... nothing?

"What happens if I just press Enter?"

So I added input validation.

if not text.strip():
    print("No input provided")
    exit()

This is a small thing, but it made me think differently about writing programs. It's not enough to make something work when everything goes perfectly.

I also need to think about: What if the user does something unexpected?
That's a useful habit to build early.

Step 3: How many sentences did I write?

For a simple version, I looked at sentence-ending punctuation.

sentence_count = text.count(".") + text.count("?") + text.count("!")
if(sentence_count) == 0:
    sentence_count = 1

Perfect? I don't need to build the world's most sophisticated NLP system for Week 1. I need to understand the problem, build something that works, and improve it as I learn.

Step 4: Time to clean things up

Shawarma
shawarma
shaWARma!
shawarmA?

Python sees these as different strings. But I don't want that. So I started *normalizing * the text. We're going to lowercase everything and remove the unnecessary punctuation. And also I need individual words. That's where *tokenization * comes in. For this simple project, splitting the text was enough.

clean_text = text


punctuation = ".,:;?!@#$%^&*()_+-="
for i in punctuation:
    clean_text = clean_text.replace(i,"")

words_list = clean_text.lower().split()

Step 5: Which words do I keep repeating?

I decided to use a dictionary. Then I loop through every word. So, just a dictionary, loop and a condition.

for word in words_list:
    if word in freq:
        freq[word] = freq[word] + 1
    else:
        freq[word] = 1

Now I have the counts. But they're not necessarily in the order I want. So I needed to sort them based on their frequency.

sorted_freq = sorted(freq.items(), key=lambda item: item[1], reverse=True)

Step 6: Give me the top N words

I didn't want to hard-code the number of words. So I added another input and formatted the output.

top_n = int(input("How many top words do you need? "))


print(f"Top {top_n} frequently repeated words:")

for word, count in sorted_freq[:top_n]:
    print(f"{word} -> {count}")

I have already got the top n value and I am going to have the for loop iterate in the sorted list of words. The end of the range parameter is the input received. So, if I got top 3, then the range goes from 0 to 2 indexes and shows the top 3 words. This is where sorting becomes handy!

Step 7: Give me the top N-grams

What I mean by this is..

These combinations can tell us something different from individual word frequency. That is n-grams, my Lady.

n_size = int(input("How many n-grams do you need? "))

n_gram_freq = {}


for i in range(0,len(words_list)-n_size+1):
    n_gram = words_list[i:i+n_size]
    gram_text = " ".join(n_gram)

    if gram_text in n_gram_freq:
        n_gram_freq[gram_text] += 1
    else:
        n_gram_freq[gram_text] = 1

sorted_ngram = sorted(n_gram_freq.items(), key=lambda item: item[1], reverse=True)

Let me quickly, break this down, so I don't get confused when I look at the program after n days.

How did I come up with this for i in range(0,len(words_list)-n_size+1): and importantly why?

So, if the input is: "I want shawarma with garlic sauce" and n-grams is 2 (that is bigrams). Then I need something like this:

i want
want shawarma
shawarma with
with garlic
garlic sauce

So the formula is: Total words - n-grams + 1

6 - 2 + 1

Then,

n_gram = words_list[i:i+n_size] gram_text = " ".join(n_gram)

which is going to take my words out from the list (i.e.) I have ['i','want'] but i need 'i want'

Now, I need a count of these grams and going to make use of n_gram_freq dict to get that.

if gram_text in n_gram_freq: n_gram_freq[gram_text] += 1 else: n_gram_freq[gram_text] = 1

Of course, if I'm counting them, I want to know which ones appear most frequently.

sorted_ngram = sorted(n_gram_freq.items(), key=lambda item: item[1], reverse=True)

print(f"Top {top_n} frequently repeated words:")
print(f"{n_size}-grams: ")

for word, count in sorted_ngram[:top_n]:
    print(f"{word} -> {count}")

Step 8: Counting syllables

Remember the rule? No external libraries. So I had to come up with a simple approach myself. I started with the vowels:

vowels = "aeiou" syll = 0

Then I went through each word and counted vowel groups. The basic idea is, if I see a vowel and the previous character wasn't a vowel, I count a syllable.

But, word like 'beautiful' has vowel groups like:
eau
i
u

The logic isn't a perfect English syllable detector. And I know that.

But for this project, I wanted to understand the logic instead of reaching immediately for a package.

vowels = "aeiou"
syll = 0

for word in words_list:
    prev_vowel = False
    word_syll = 0

    for letter in word:
        if letter in vowels and prev_vowel == False:
            word_syll += 1

        prev_vowel = letter in vowels

    if word_syll==0:
        word_syll = 1   

    syll += word_syll

Step 8: Readability score

I wanted to calculate a readability score. I used the Flesch Reading Ease formula.

The formula uses:

Number of words
Number of sentences
Number of syllables

The formula is:

206.835 - 1.015 × (words / sentences) - 84.6 × (syllables / words)

score = 206.835 - (1.015*(word_count/sentence_count)) - (84.6*(syll/word_count))
print(f"Readability score: {score:.2f}")

A simple Python script has gone from:

"Give me some text."

to:

"Here's what I can tell you about that text."

The project itself is small. But I ended up touching quite a few Python concepts:

User input
Input validation
Strings
String methods
Lists
Dictionaries
Loops
Conditions
Slicing
sorted()
lambda
List processing
Word frequency
N-grams
Basic text processing
Readability calculations

Is this code perfect? No. And that's okay.
I don't want to spend Week 1 trying to build a production-ready NLP library.

I'm starting with Python fundamentals because I know I need a stronger foundation before I start building more serious AI and GenAI projects.

And I want to remind myself of something:

I don't need to know everything before I start. I just need to start.

So, Nattar... Come back tomorrow again!

You can find the complete project on Github:
👉 Week 1 - Day 1 - Text Analyzer in Python

DEV Community: Nattar Kani Murugan

Day 4: Building a Library Management System with Python OOP | 10 Weeks Challenge | To AI Engineer

First, I needed a map

Step 1: Start with abstraction

Step 2: What can actually be borrowed?

Step 3: Creating the actual items

Wait... why multiple inheritance?

Step 4: DVD can use the same behaviour

Step 5: Not everything needs borrowing

Step 6: Dataclasses saved me from boilerplate

Step 7: I finally used some dunder methods

Step 8: Who manages everything?

Step 9: Borrowing an item

Step 10: A loan is its own object

And then... mypy

What did I actually learn?

The mind map helped more than I expected

🔗 The project

Day 3: Learning Decorators by Building My Own Python Library

First... what is a decorator?

My five decorators

1. log_calls

2. timeit

3. retry

4. cache

5. validate

And then I thought...

What did I learn today?

Day 3: Done. ✅

Day 2: Comprehensions & My First Generator-Based File Reader | Python | Day 2 | Week 1 | 10 Week Challenge

Text Analyzer | Python | Day 1 | Week 1| 10WeekChallenge

So, what does this thing actually do?

Step 1: Okay, give me some text

Step 2: But what if I give it... nothing?

Step 3: How many sentences did I write?

Step 4: Time to clean things up

Step 5: Which words do I keep repeating?

Step 6: Give me the top N words

Step 7: Give me the top N-grams

Step 8: Counting syllables

Step 8: Readability score

1. `log_calls`

2. `timeit`

3. `retry`

4. `cache`

5. `validate`