Python File Handling and Django Config Files

Day 18 of my Python Full Stack journey. ✅ Today's topic: Inheritance — one of the most powerful concepts in OOP. Instead of writing the same code twice — you inherit it from a parent class. Here's what I typed today: # Parent class class Person: def __init__(self, name, age): self.name = name self.age = age def introduce(self): return f"Hi, I'm {self.name}, {self.age} years old." # Child class — inherits from Person class Student(Person): def __init__(self, name, age, course): super().__init__(name, age) # inherits parent __init__ self.course = course # Method overriding — redefining parent method def introduce(self): return f"Hi, I'm {self.name}. I study {self.course}." s1 = Student("Punith", 24, "Python Full Stack") print(s1.introduce()) # Hi, I'm Punith. I study Python Full Stack. 3 things that clicked today: → super() calls the parent class — no need to rewrite __init__ → Child class can override any parent method → Child class can also add brand new methods of its own Why this matters for Django: → Django's Model class is a parent class → When you write 'class Student(models.Model)' — you are inheriting from Django's Model → That one line gives your class database superpowers #PythonFullStack #Day18 #Inheritance #OOP #BuildingInPublic #100DaysOfCode #Bangalore

Day 16 of my Python Full Stack journey. ✅ Today's topic: OOP — Object Oriented Programming. The biggest concept in Python so far. And the most important one for Django. Here's what clicked today: Everything in Python is an object. A class is just a blueprint for creating objects. Here's what I typed today: # Class = blueprint class Student: def __init__(self, name, marks): self.name = name self.marks = marks def result(self): if self.marks >= 50: return f"{self.name} — Pass ✅" return f"{self.name} — Fail ❌" # Object = actual instance built from blueprint s1 = Student("Punith", 88) s2 = Student("Rahul", 42) print(s1.result()) # Punith — Pass ✅ print(s2.result()) # Rahul — Fail ❌ Why this matters for Django: → Every Django Model is a class → Every Django View can be a class → Every Django Form is a class If you don't understand OOP — Django will feel like magic. If you do — Django will feel like logic. Today Django finally started making sense. 🤯 What concept made Django finally click for you? #PythonFullStack #Day16 #OOP #BuildingInPublic #100DaysOfCode #Bangalore

Day 20 of my Python Full Stack journey. ✅ Today I did something most learners skip. Revision. Before jumping into — Advanced Python + Django — I went back and revised everything from first 4 weeks. Here's what I revised today: → Variables, Data Types, f-strings → Conditionals — if, elif, else → Loops — for, while, range() → Functions — *args, **kwargs, default arguments → Lists, Dictionaries, Tuples, Sets → Nested Data Structures → File Handling — read, write, append → OOP — Classes, Methods, Inheritance Why revision matters: Moving fast feels productive. But building on a shaky foundation always breaks later. Today I made sure my foundation is solid. So when Django hits — nothing feels alien. One thing that surprised me during revision: How much more sense OOP makes now compared to Day 16. Same concept. Completely different level of understanding. That's what consistency does. 💪 Day 21 tomorrow — Month 2 officially begins. List comprehensions, Lambda, Map, Filter. Advanced Python starts now. 🚀 What's the one Python concept you wish you had revised before moving to Django? #PythonFullStack #Day21 #Revision #BuildingInPublic #100DaysOfCode #Bangalore

Day 12 of my Python Full Stack journey. ✅ Today's topic: Functions Deep Dive — the parts most beginners skip. *args and **kwargs. Looked confusing at first. Made complete sense after 45 minutes. Here's what I typed today: # Default arguments def greet(name, role="Developer"): print(f"Hey {name}, future {role}!") # *args — multiple positional arguments def add_all(*numbers): return sum(numbers) print(add_all(1, 2, 3, 4)) # 10 # **kwargs — multiple keyword arguments def show_info(**details): for key, value in details.items(): print(f"{key}: {value}") show_info(name="Punith", city="Bangalore", stack="Python") Why this matters for Django: → Django views use *args and **kwargs everywhere → Every class based view passes **kwargs automatically → Understanding this now saves hours of confusion later Pushed to GitHub immediately. Lesson learned. ✅ #PythonFullStack #Day12 #BuildingInPublic #100DaysOfCode #Bangalore

Do you know what Django, SQLAlchemy, and Pydantic all have in common? They are all built on metaclasses. Day 04 of 30 -- Metaclasses and Class Creation Advanced Python + Real Projects Series When you write class Order(Table): in Django, something runs before a single instance is created. The metaclass intercepts the class definition itself, reads your field declarations, and builds the SQL schema automatically. That is not magic. That is type. Today's topic covers: Why classes are objects and what that actually means The 3-level hierarchy -- type, class, instance The 5-step class creation lifecycle Python runs for every class keyword 4 approaches -- full metaclass, init_subclass, type(), class_getitem Full annotated syntax -- building a field-validation metaclass from scratch Real mini ORM -- auto-generate CREATE TABLE SQL from class definitions How Django, SQLAlchemy, Pydantic, abc, and enum all use this internally 4 mistakes including the metaclass conflict that breaks multiple inheritance Key insight: You do not need to write metaclasses often. But you need to understand them to read any serious Python framework. #Python #PythonProgramming #Django #SQLAlchemy #SoftwareEngineering #BackendDevelopment #100DaysOfCode #LearnPython #PythonDeveloper #TechContent #DataEngineering #BuildInPublic #TechIndia #CleanCode #LinkedInCreator #PythonTutorial

Just shipped stup 🚀 A python package that scaffolds production-ready Python projects in seconds. 🛠️ Every time I started a new project, I was doing the same thing: init uv, pin Python, create venv, wire up requirements.txt, set up folders. 10 minutes of setup before writing a single line of actual code. ⏳ stup kills that loop. One command, full scaffold⚡ → `stup django` : Django + DRF + Celery + Redis + PostgreSQL, ready to go → `stup lang-agent` : LangGraph agent with tools, memory, Ollama config → `stup react-fastapi` : Full-stack with Docker Compose and CORS pre-wired → `stup ml` : MLflow + PyTorch + scikit-learn experiment structure → `stup cli` : PyPI-ready package with Typer + Rich, entry_points set All templates build on top of `stup uv` which handles uv init, Python pinning, and venv in one shot. Install once: `pip install stup` source code: https://lnkd.in/duGUCXVH

Understanding Django's .get_or_create() Pattern A pattern I see frequently misunderstood in Django codebases: This returns a tuple of (instance, boolean). The comma performs standard Python iterable unpacking—it's not Django-specific syntax. Common mistake: Treating the unpacked variables as a single unit. They're independent references. obj is a fully editable model instance, and created is simply a boolean indicating whether a new record was inserted. Practical application—handling placeholder records: Consider a ProjectMembership model where new clients are created with project=None as a placeholder. This pattern: Finds the existing placeholder if present Creates one if absent Updates the project reference in either case Result: The placeholder is upgraded rather than orphaned. No duplicate records. No cleanup required. Key takeaway: .get_or_create() followed by assignment provides atomic-like "get or upsert" semantics without race conditions that plague separate get-then-create logic. This protection only works if there's a database-level unique constraint on the lookup fields (or Django's unique_together in Meta). Without it, .get_or_create() still has a race condition window. The database constraint is what guarantees atomicity. #Django #Python #BackendEngineering #SoftwareDevelopment

🚀 From Learning Python to Understanding Backend Systems When I first started learning Python, my focus was mainly on syntax and basic problem-solving. But as I explored more, I realized that backend development is where logic meets real-world application. That’s when I began diving deeper into the Python backend ecosystem. Instead of just learning tools, I started understanding how backend systems actually work—how requests are processed, how data flows between the server and database, and how APIs connect everything together. 🔧 Tools & Technologies I’m Exploring: • Python for core logic • Django for structured and scalable applications • Flask / FastAPI for lightweight API development • Relational Databases for data management • REST APIs for communication between systems • Git & GitHub for version control • JWT for authentication • Basic backend security practices • Deployment fundamentals 💡 What Changed in My Approach: Earlier, I focused on “what to learn.” Now, I focus on “how things work.” This shift helped me: • Understand backend architecture more clearly • Write better and cleaner code • Think like a developer instead of just a learner I’m still at the beginning of this journey, but I’m consistently building, experimenting, and improving every day. The goal is simple — to become a backend developer who not only writes code, but understands the system behind it. Excited for what’s ahead 🚀 #Python #BackendDevelopment #Django #Flask #FastAPI #RESTAPI #LearningJourney #SoftwareDevelopment #snsinstitutions #snsdesignthinkers #designthinking

📌 One thing I underestimated while learning Django: The database. At first, I thought: "Models are just tables." But while building projects, I realized: 👉 Database design decides how clean your backend will be. Bad design = complicated queries + repeated logic + messy relationships Good design = simpler views + cleaner APIs + better performance Now I spend more time thinking about models before writing views. Your code depends on your data structure more than you think. Do you plan your database first or just start coding? #Django #BackendDevelopment #Python #LearningInPublic

🚀 Not every day needs to be posted… but every day needs progress. While I’ve been a little silent here, I’ve been consistently working behind the scenes — focusing on what truly matters: building strong fundamentals. 💡 Over the past few days, I’ve been: • Sharpening logic building & problem-solving skills • Practicing and implementing concepts in Python & SQL • Building and refining projects using HTML, CSS, and Django • Focusing on writing clean, structured, and efficient code This phase isn’t about speed — it’s about clarity, depth, and real understanding. I’ve learned that: 👉 Strong basics = Real confidence 👉 Consistency > Motivation 👉 Small daily improvements create big results No shortcuts. Just discipline, practice, and growth. 📈 Back again — stronger, clearer, and more focused! #LearningJourney #Consistency #GrowthMindset #Python #WebDevelopment #Django #SQL #PlacementPreparation #KeepBuilding 🚀