Python Functions Deep Dive with *args and **kwargs

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 17 of my Python Full Stack journey. ✅ Today's topic: The 3 types of methods in OOP. Most beginners only know one. Here's all three explained simply. Here's what I typed today: class Student: school = "Acharya Institute" # class variable def __init__(self, name, marks): self.name = name # instance variable self.marks = marks # Instance method — works with one object def result(self): return f"{self.name}: {'Pass' if self.marks >= 50 else 'Fail'}" # Class method — works with the class itself @classmethod def school_name(cls): return f"School: {cls.school}" # Static method — independent, no self or cls @staticmethod def passing_marks(): return "Passing marks: 50" s1 = Student("Punith", 88) print(s1.result()) # instance method print(Student.school_name()) # class method print(Student.passing_marks()) # static method Simple rule: → Instance method — needs object data (use self) → Class method — needs class data (use cls) → Static method — needs neither. Just a helper function. Did you know all 3 types of methods before reading this? #PythonFullStack #Day17 #OOP #BuildingInPublic #100DaysOfCode #Bangalore

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

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

📌 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

Day 7 of my Python Full Stack journey. ✅ Today's topic: Dictionaries — the most important data structure in Python. A dictionary stores data as key-value pairs. Think of it like a real dictionary — word (key) and its meaning (value). Here's what I typed today: student = { "name": "Punith", "age": 24, "course": "Python Full Stack" } # Access print(student["name"]) # Punith # Add / Update student["city"] = "Bangalore" # Loop through for key, value in student.items(): print(f"{key}: {value}") Why this matters for Django: Every Django model, every API response, every JSON data — all dictionary-like. If you understand dictionaries, Django will make sense. 60 minutes done. Pushed to GitHub. Day 8 tomorrow. One week and 2 days in. Still showing up. 💪 #PythonFullStack #Day7 #Dictionaries #BuildingInPublic #100DaysOfCode #Bangalore

Every time you write obj.attribute in Python, something runs that most developers have never heard of. Day 05 of 30 -- Descriptors and Properties Advanced Python + Real Projects Series When Django marks a field dirty on assignment, when SQLAlchemy tracks changes for save(), when Pydantic validates on every write -- they all use the same mechanism. The descriptor protocol. A descriptor is any object defining get, set, or delete. When it sits as a class attribute, Python routes all attribute access through it -- before the instance dict is even touched. Today's Topic covers: Why descriptors exist and what problem @property alone cannot solve The full descriptor protocol -- get, set, delete, set_name Data vs non-data descriptors and why the difference controls lookup priority The 3-level attribute lookup chain Python follows on every access Annotated syntax -- from @property to a fully reusable Validated field Real e-commerce scenario -- auto type check, range validation, and audit logging on every field write across 30 model classes with 3 lines of code How Django, SQLAlchemy, Pydantic, and dataclasses all use this internally 4 mistakes including the infinite recursion trap that kills production apps Key insight: When you write user.email in Django, that single line triggers a descriptor that queues the change for save(). No magic. Just the descriptor protocol. #Python #PythonProgramming #Django #SQLAlchemy #SoftwareEngineering #BackendDevelopment #100DaysOfCode #LearnPython #PythonDeveloper #TechContent #DataEngineering #BuildInPublic #TechIndia #CleanCode #LinkedInCreator #PythonTutorial

If you’ve ever felt like type hints in Python are getting…out of hand, you’re not alone. In this talk, Carlton Gibson (Django Steering Council) breaks down a real tension: Python was designed to stay dynamic, and type hints were never meant to be mandatory. But today, many teams feel pressure to add them anyway. Consider #Django, for example: • It’s built on dynamic patterns (introspection, minimal boilerplate, etc.). • Static typing often can’t fully represent those patterns. • Adding types can increase complexity without real safety gains. • Sometimes you’re just repeating yourself to satisfy the type checker. So what’s the alternative? Don’t force typing where it doesn’t fit. Keep Python dynamic – and add types where they actually bring value. The key takeaway: Instead of rewriting frameworks like Django, build typed layers on top – keeping flexibility while adding structure where needed. Don’t think “types vs. no types.” Think about using the right tool in the right place. ▶️ Watch the full talk: https://lnkd.in/eptmtpHj #Python #Django #TypeHints #StaticTyping #WebDevelopment

Day 14 of my Python Full Stack journey. ✅ Today's topic: File Handling — making data survive after the program closes. This is where Python stops feeling like exercises and starts feeling like real software. Here's what I typed today: # Writing to a file with open("students.txt", "w") as file: file.write("Punith: 88\n") file.write("Rahul: 92\n") # Reading from a file with open("students.txt", "r") as file: content = file.read() print(content) # Appending to a file with open("students.txt", "a") as file: file.write("Priya: 76\n") Biggest lesson today: Always use 'with open()' instead of just open(). It automatically closes the file even if an error occurs. One line saves you from a lot of headaches. ✅ Why this matters for Django: → Django reads config files on startup → Log files track every request your app receives → Media uploads are files stored on your server Understanding file I/O now makes all of that make sense later. Two weeks done. Still showing up every single day. 💪 #PythonFullStack #Day14 #BuildingInPublic #100DaysOfCode #Bangalore

Python 3.14 just dropped something I didn't know I needed. t-strings. For years I've been using f-strings for everything. They're clean, they're fast, and I love them. But there's always been that one nagging problem — you can't intercept what goes inside them. The moment you write f"Hello {user_input}", that string is already built. No hooks. No validation. No custom logic. Just a finished string. t-strings change that completely. Instead of immediately resolving to a string, t"Hello {user_input}" gives you back a Template object. You get both the static parts and the interpolated values — separately — before anything is joined together. That means you can sanitize SQL inputs, escape HTML, validate API payloads, or run any custom logic on the values before they ever become a string. The syntax feels identical to f-strings. The power underneath is completely different. I've already started thinking about how this simplifies things in backend work — especially anywhere user input touches a query or a template. The safety implications alone are massive. This is one of those features that looks small in the changelog and then quietly becomes the way you write Python. Have you tried t-strings yet? What's your first use case? #Python #Python3.14 #BackendDevelopment #SoftwareEngineering #WebDevelopment