Python Collections Cheat Sheet: List, Set, Dict, Tuple

Why Python Code Becomes Hard to Maintain 🧩 Python is known for being clean and readable. Yet many Python projects become painful to maintain after a few months. The irony? The language isn’t the problem—the way it’s written is. Hard-to-maintain Python code usually leads to: ▪️Fear of touching existing files ▪️Bugs appearing after “small changes” ▪️Long debugging sessions for simple fixes You open the code, stare at it, and ask: “Why is this so hard to understand?” This happens more often than most developers admit. The good news is this: Unmaintainable Python code is not caused by complexity, it’s caused by small, repeated decisions. Once you spot them, your codebase becomes easier to read, extend, and debug. Solution Here are two common patterns that quietly destroy maintainability 👇 ❌ Example 1: Vague Naming ''' def process(d): for x in d: if x > 10: do(x) ''' At first glance, it works. But process what? what is d? what is x? ✅ Better Direction: ''' def process_scores(scores): for score in scores: if score > 10: handle_passing_score(score) ''' Clear names reduce the need for comments and future confusion. ❌ Example 2: Doing Too Much in One Function ''' def register_user(data): validate(data) save_to_db(data) send_email(data) log_activity(data) ''' This function grows fast. Any change affects everything. ✅ Better Direction: Break responsibilities into smaller, focused functions. When one thing changes, the rest stays stable. Key Reasons Python Code Becomes Hard to Maintain: ▪️Poor naming ▪️Long, multi-purpose functions ▪️No clear structure or separation of concerns Quick Self-Check: ✔ Can someone else understand this function in 10 seconds? ✔ Does this function do one thing well? ✔ Would a small change cause side effects? If your Python code feels fragile, it’s not because Python is simple—it’s because simplicity wasn’t enforced. #PythonProgramming #PythonDevelopers #PythonCode #SoftwareDevelopment #CodingLife #CleanCode #CodeQuality #MaintainableCode #BestPractices #Refactoring #LearnPython #ProgrammingTips #DeveloperLife #TechCommunity #BackendDevelopment #PythonProgramming #CleanCode #MaintainableCode #SoftwareDevelopment #PythonDevelopers #Refactoring #CodingLife #ProgrammingTips

What usually makes code hard for you to maintain? 🔹 Poor naming 🔹 Long functions 🔹 No structure 🔹 Someone else’s code 😅

🎯𝗗𝗮𝘆 𝟮/𝟯𝟬 – 𝟯𝟬-𝗗𝗮𝘆𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲🔥 Day 2 complete.📝 Today was less about syntax… and more about thinking logically. I focused on Control Flow and Functions in Python — basically how programs make decisions and how we avoid repeating code. Here’s what I learned (and revised) today 𝟭. 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗙𝗹𝗼𝘄 – Teaching Code to Think Programming isn’t just writing instructions. It’s teaching the system how to decide. -Conditional Statements (if, elif, else) This is where logic begins. if condition: # execute this elif another_condition: # execute this else: # fallback Python checks conditions from top to bottom. Only the first true condition runs. It reminded me that order matters — 𝗶𝗻 𝗰𝗼𝗱𝗲 𝗮𝗻𝗱 𝗶𝗻 𝗹𝗶𝗳𝗲. Loops help us repeat tasks efficiently. 𝗳𝗼𝗿 𝗹𝗼𝗼𝗽 → when we know how many times to run. for i in range(5): print(i) 𝘄𝗵𝗶𝗹𝗲 𝗹𝗼𝗼𝗽 → when execution depends on a condition. while condition: # keep running 𝗯𝗿𝗲𝗮𝗸 → stops the loop immediately 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 → skips current iteration 𝗽𝗮𝘀𝘀 → placeholder 𝟮. 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀 – Write Once, Use Many Times This was my favorite part today. Instead of repeating code again and again, we define functions. def greet(name): return f"Hello {name}" *𝗮𝗿𝗴𝘀 → accepts multiple positional arguments (stored as tuple) **𝗸𝘄𝗮𝗿𝗴𝘀 → accepts multiple keyword arguments (stored as dictionary) 𝗟𝗘𝗚𝗕 𝗥𝘂𝗹𝗲 (𝗩𝗮𝗿𝗶𝗮𝗯𝗹𝗲 𝗦𝗰𝗼𝗽𝗲) Python searches variables in this order: 𝗟𝗼𝗰𝗮𝗹 → 𝗘𝗻𝗰𝗹𝗼𝘀𝗶𝗻𝗴 → 𝗚𝗹𝗼𝗯𝗮𝗹 → 𝗕𝘂𝗶𝗹𝘁-𝗶𝗻 Scope clarity = fewer debugging headaches. 𝗥𝗲𝗰𝘂𝗿𝘀𝗶𝗼𝗻 A function calling itself. Powerful, but must have a base condition, otherwise it runs forever. 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗼𝗿𝘀 (𝘆𝗶𝗲𝗹𝗱) Unlike return, which ends a function, yield pauses it and resumes later. Generators don’t store all values in memory — they generate values one by one. 𝗹𝗮𝗺𝗯𝗱𝗮 → small anonymous functions 𝗺𝗮𝗽() → transform data 𝗳𝗶𝗹𝘁𝗲𝗿() → filter data 𝗿𝗲𝗱𝘂𝗰𝗲() → reduce list to single value It showed me there are multiple ways to solve the same problem — and choosing the right one matters. 𝗛𝗶𝗴𝗵𝗲𝗿-𝗢𝗿𝗱𝗲𝗿 𝗙𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝘀, 𝗖𝗹𝗼𝘀𝘂𝗿𝗲𝘀 & 𝗣𝗮𝗿𝘁𝗶𝗮𝗹 Today I learned that in Python: Functions can accept other functions. Functions can return functions. Inner functions can remember outer variables (Closures). We can pre-fill arguments using partial(). This made Python feel powerful and elegant. 📝 𝗥𝗲𝗳𝗹𝗲𝗰𝘁𝗶𝗼𝗻 – 𝗗𝗮𝘆 𝟮 Today wasn’t about writing long programs. It was about: - Understanding flow - Structuring logic -Writing smarter code - Thinking like a programmer I’m realizing something: The more I learn fundamentals deeply, the more confident I feel moving forward. Consistency > Motivation. 28 days to go. #𝟯𝟬𝗗𝗮𝘆𝘀𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲 #𝗣𝘆𝘁𝗵𝗼𝗻 #𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴𝗜𝗻𝗣𝘂𝗯𝗹𝗶𝗰 #𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 #𝗦𝗮𝗵𝗮𝗻𝗮.𝗕𝘂𝗶𝗹𝗱s #𝗗𝗮𝘆𝟮

🧠 Python Concept You MUST Know: __slots__ (Memory Optimization in Classes) Most Python developers never use __slots__, but those who do understand Python deeply. Let’s explain it simply 👇 🧒 Simple Explanation Imagine each student gets a school bag 🎒. Normally, the bag is big and flexible — you can put anything inside. But sometimes, you want a small, fixed bag that holds only specific items. That’s what __slots__ does. 🔹 Normal Class (Flexible but Heavy) class Person: def __init__(self, name, age): self.name = name self.age = age Each object: ✔️ Has a dictionary (__dict__) ✔️ Uses more memory ✔️ Can add new attributes anytime 🔹 Class with __slots__ (Lightweight) class Person: __slots__ = ("name", "age") def __init__(self, name, age): self.name = name self.age = age Now: ✔ No __dict__ ✔ Less memory per object ✔ Faster attribute access ✔ No extra attributes allowed 🤯 What Happens If You Try This? p = Person("Sam", 20) p.height = 170 ❌ Error: AttributeError: 'Person' object has no attribute 'height' Because __slots__ locks the structure. 🚀 When Should You Use __slots__? Use it when: ✔ You create many objects ✔ Memory matters ✔ Object structure is fixed ✔ Performance is important Used heavily in: 🖥️ Game engines 🖥️ Data models 🖥️ High-performance systems ⚠️ When NOT to Use It Avoid __slots__ when: ✖ You need flexibility ✖ You dynamically add attributes ✖ You’re still prototyping 🎯 Interview Gold Line “__slots__ removes the instance dictionary to reduce memory usage.” Short. Powerful. Correct. 🧠 One-Line Rule Use __slots__ for many objects with fixed attributes. ✨ Final Thought __slots__ is not about writing less code — it’s about writing smarter Python. 📌 Save this post — this is an advanced Python skill. #Python #LearnPython #PythonDeveloper #PythonTips #__slots__ #MemoryOptimization #PythonInternals #CleanCode #Performance #SoftwareEngineering #TechLearning #DeveloperLife

If you’re a Python developer who writes more than the occasional small script, you already know the truth: threads in Python are one of the longest-running frustrations in the language. But now, Python has finally decided it’s time to grow up. The most recent Python release introduces one of the boldest and most far-reaching changes the language has ever seen: official support for Free Threading. 𝐏𝐲𝐭𝐡𝐨𝐧 𝐚𝐧𝐝 𝐓𝐡𝐫𝐞𝐚𝐝𝐬: 𝐓𝐡𝐢𝐫𝐭𝐲 𝐘𝐞𝐚𝐫𝐬 𝐨𝐟 𝐒𝐨𝐥𝐢𝐭𝐮𝐝𝐞 Python is no longer a young language. Created nearly 35 years ago by Guido Van-Rossum, and with Python 3 released back in 2008, it has proven itself across countless domains and applications. Yet in one important area, the language has long carried an implementation that is hard to justify in a mature ecosystem: thread support. CPython, the most common implementation, never truly got along with threads.   Proper thread support is difficult. It demands careful handling of race conditions, deadlocks, shared state, and memory management. When all of this is embedded in a dynamic interpreter with pervasive object sharing and a garbage collector, the challenge becomes far greater than in a tightly bounded application. 𝐋𝐨𝐨𝐤𝐬 𝐋𝐢𝐤𝐞 𝐚 𝐓𝐡𝐫𝐞𝐚𝐝. 𝐅𝐞𝐞𝐥𝐬 𝐋𝐢𝐤𝐞 𝐚 𝐓𝐡𝐫𝐞𝐚𝐝. 𝐁𝐮𝐭 𝐈𝐬𝐧’𝐭 𝐚 𝐓𝐡𝐫𝐞𝐚𝐝. From an early stage, Python’s solution was awkward but effective: allow concurrency, forbid true parallelism. Multiple threads can exist and run concurrently, but not in parallel. Even on multi-core systems, only one thread executes Python bytecode at any given moment. This is enforced by the GIL (the Global Interpreter Lock) which ensures that only a single thread runs Python code at a time. So why have threads at all? For I/O-bound workloads, they still help: while one thread waits for I/O, another can run. Some computation-heavy libraries achieve true parallelism through specialized native code. But in general, anyone wanting Python to scale across CPU cores has had to rely on multiple processes. 𝐅𝐫𝐞𝐞-𝐓𝐡𝐫𝐞𝐚𝐝𝐢𝐧𝐠 𝐏𝐲𝐭𝐡𝐨𝐧: 𝐓𝐡𝐢𝐬 𝐈𝐬 𝐇𝐨𝐰 𝐈𝐭 𝐒𝐭𝐚𝐫𝐭𝐬 In recent years, a serious effort has been underway to free Python from the GIL. The previous release introduced this capability experimentally. Python 3.14 takes the most decisive step yet: for the first time, Python officially supports running without the GIL. This is not the default. Running without the GIL requires explicit configuration. Not out of conservatism, but because of the magnitude of the change and the costs it carries, like performance penalties and breaking existing code. For these reasons, the Python steering committee has not set a target date for making GIL-less execution the default. Over the coming years, the mechanism will be tested in real systems, its impact better understood, and performance overhead reduced. When will that happen? We’ll have to wait for the decision of the (former) benevolent dictator and his council.

Most Python code works. Very little Python code scales. The difference? 👉 Object-Oriented Programming (OOPS). As part of rebuilding my Python foundations for Data, ML, and AI, I’m now focusing on OOPS — the layer that turns scripts into maintainable systems. Below are short, practical notes on OOPS — explained the way I wish I learned it 👇 (No theory overload, only what actually matters) 🧠 Python OOPS — Short Notes (Practical First) 🔹 1. Class & Object A class is a blueprint. An object is a real instance. class User: def __init__(self, name): self.name = name u = User("Anurag") Used to model real-world entities (User, File, Model, Pipeline) 🔹 2. __init__ (Constructor) Runs automatically when an object is created. Used to initialize data. def __init__(self, x, y): self.x = x self.y = y 🔹 3. Encapsulation Keep data + logic together. Control access using methods. class Account: def get_balance(self): return self.__balance Improves safety & maintainability 🔹 4. Inheritance Reuse existing code instead of rewriting. class Admin(User): pass Used heavily in frameworks & libraries 🔹 5. Polymorphism Same method name, different behavior. obj.process() Makes systems flexible and extensible 🔹 6. Abstraction Expose what a class does, hide how it does it. from abc import ABC, abstractmethod Critical for large codebases & APIs OOPS isn’t about syntax. It’s about thinking in systems, not scripts. #Python #OOPS #DataEngineering #LearningInPublic #SoftwareEngineering #AIJourney

Every piece of data your Python program touches has a type. A username. An account balance. A list of IP addresses. Whether a door is locked or unlocked. Data types define what a value is, what you can do with it, and whether it can be changed after creation. And if you don't understand them, everything else in Python gets harder. I just published a complete guide covering every built-in Python data type: -- Mutable vs. immutable (and why it matters more than you think) -- Strings, integers, floats, and booleans -- Lists, tuples, dictionaries, and sets -- NoneType (Python's version of "nothing") -- How to safely convert between types Every section includes real code examples you can run immediately. This isn't optional knowledge you circle back to later. It's the foundation everything else is built on. https://lnkd.in/gNwfhVnG #Python #PythonProgramming #LearnPython #CodingForBeginners #Programming #DataTypes #PythonTutorial #SoftwareDevelopment

Ever wondered why your Python script slows down when your data grows? 🐍 I used to think of Lists and Dictionaries as just simple "containers," but digging into how Python handles memory "under the hood" changed my perspective on writing efficient code. In my latest blog post, I break down: 🔹 The "Moving Day" problem: How Lists actually grow in memory. 🔹 The Library GPS: Why Dictionaries are so much faster than Lists. 🔹 Why Tuples are the lightweight "speedsters" of Python. If you're a student or developer looking to move from just "making it work" to "making it smart," this one is for you. #Python #Coding #DataStructures #SoftwareEngineering #LearningJourney

🐍 An Interesting (and Sneaky) Python Bug I Ran Into I’ve been working through Fluent Python recently, and one part, "Mutable Types as Parameter Defaults: Bad Idea", reminded me of a classic pitfall that even experienced developers stumble into: using mutable objects as default parameters. It looks innocent enough: def add_item(item, container=[]): container.append(item) return container But here’s the twist: Python evaluates default parameter values only once—when the function is defined, not each time it’s called. So instead of getting a fresh list every call, you get shared state: add_item(1) # [1] add_item(2) # [1, 2] # surprise! This behavior is intentional, but it can lead to subtle, head‑scratching bugs if you’re not expecting it. The safe pattern is: def add_item(item, container=None): if container is None: container = [] container.append(item) return container Why This Bug Doesn’t Happen in C# or C++ One thing I appreciate about strongly typed languages is how their design choices prevent entire categories of bugs. C# C# requires that default parameters be compile‑time constants: numbers, strings, enums, null You cannot use a mutable object as a default: void Foo(List<int> xs = new List<int>()); // ❌ compile error This rule completely eliminates Python’s shared‑mutable‑default issue. C++ C++ also avoids the problem, but for a different reason. Default arguments in C++ are compile‑time expressions, and they are substituted at the call site, not stored in the function object. This is allowed: void foo(const std::vector<int>& v = std::vector<int>()); // ✔ OK But the key detail is: a new temporary object is created every time the function is called. So there’s no shared state, and no Python‑style surprise. Takeaway Python’s flexibility is powerful, but it comes with sharp edges. C# and C++ take a stricter, compile‑time‑driven approach that prevents this entire class of bugs. If you’re writing Python APIs or utilities, it’s worth double‑checking your default parameters. A tiny detail can lead to some very unexpected behavior.