Debasis Bhattacharjee

The most practically useful Python patterns are: Singleton (via module-level objects or metaclass) Factory (via functions not classes) Strategy (via first-class functions) Observer (via callbacks or event systems) and Decorator (using Python's native decorator syntax). Python's first-class functions make many GoF patterns simpler or unnecessary.

Deep Dive: Python's features change how classic patterns are implemented. Singleton: in Java you implement a private constructor with a static instance. In Python a module-level instance is already a singleton — module state is shared across all imports. Factory Method: in Java a separate factory class. In Python a function or callable that returns the right type is sufficient — first-class functions eliminate the need for a factory class hierarchy. Strategy: in Java each strategy is a class implementing an interface. In Python pass the strategy function directly — no class needed. Decorator: Python has native decorator syntax making this pattern trivially implementable. Observer/Event: Python's callable objects and collections of callbacks implement this cleanly without interface boilerplate. The key insight: Python's dynamic typing first-class functions and duck typing make many patterns simpler and reduce the class hierarchy complexity required in statically typed languages.

Real-World: Django's middleware system is a chain-of-responsibility pattern implemented as callable objects. Flask's signal system (blinker) is an Observer pattern. SQLAlchemy's session uses Unit of Work pattern. Python's built-in sorted() function's key parameter is a Strategy pattern using first-class functions — sorted(users key=lambda u: u.last_name) passes the sorting strategy as a function.

⚠ Common Mistakes: Implementing Java-style patterns verbatim in Python (creating unnecessary class hierarchies). Not leveraging Python's first-class functions to simplify Strategy Command and Factory patterns. Implementing Singleton as a class when a module-level instance or functools.lru_cache(maxsize=None) serves the same purpose more simply.

🏭 Production Scenario: A Python service implemented a complex Factory class hierarchy (AbstractFactory ConcreteFactory AbstractProduct ConcreteProduct) in Java style. Code review replaced it with a registry dictionary mapping string keys to constructor functions — 5 lines instead of 50 with identical functionality and better extensibility.

Follow-up questions: What is the difference between a class decorator and a function decorator? How do you implement an event system in Python? What is the Repository pattern and how does it apply to Python ORMs?

// ID: PY-ADV-005  ·  DIFFICULTY: 7/10  ·  ★★★★★★★☆☆☆

A metaclass is the class of a class — it controls how classes themselves are created. Use them when you need to enforce constraints auto-register classes or modify class definitions at creation time.

Deep Dive: In Python everything is an object including classes. The default metaclass is 'type'. When Python processes a class definition it calls the metaclass to build the class object. By creating a custom metaclass (inheriting from type and overriding __new__ or __init__) you can intercept class creation and modify or validate it. Practical uses include: enforcing that all subclasses implement certain methods automatically registering plugin classes in a registry adding logging to all methods automatically and implementing singleton patterns. Django's ORM uses metaclasses to convert class-level field declarations into actual database schema mappings.

Real-World: Django's Model metaclass (ModelBase) reads the field attributes you declare on a model class and builds the database schema query interface and validation logic automatically. Without metaclasses Django's ORM syntax would require explicit registration calls for every model field.

⚠ Common Mistakes: Overusing metaclasses for problems that class decorators or __init_subclass__ solve more simply. Metaclasses from different libraries conflicting when a class inherits from both (metaclass conflict). Writing metaclasses that are so abstract they become impossible to debug.

🏭 Production Scenario: An internal plugin system at a SaaS company used a metaclass to automatically register all subclasses of a BasePlugin class into a global plugin registry. This eliminated the need for manual plugin registration and prevented the recurring production bug where developers created a plugin class but forgot to register it.

Follow-up questions: What is __init_subclass__ and how does it compare to metaclasses? How does 'type' work as a metaclass? What causes a metaclass conflict?

// ID: PY-ADV-001  ·  DIFFICULTY: 8/10  ·  ★★★★★★★★☆☆

Python uses reference counting as the primary memory management mechanism supplemented by a cyclic garbage collector to handle reference cycles. Memory is allocated from private heaps managed by the Python memory manager.

Deep Dive: Every Python object has a reference count. When you assign a variable or pass an object to a function the count increases. When a reference goes out of scope or is deleted the count decreases. When the count reaches zero memory is freed immediately. The problem is reference cycles: object A references B B references A — neither count reaches zero. Python's gc module handles this with a generational garbage collector that periodically identifies and clears cycles. Objects are sorted into three generations based on survival — most objects die young (generation 0) so the GC focuses there. You can trigger collection manually with gc.collect() and disable it in performance-critical code if you are certain there are no cycles.

Real-World: A long-running FastAPI service was growing in memory over days. Profiling with tracemalloc revealed a reference cycle in a caching layer where cached response objects held references back to the cache container. Explicitly breaking the cycle with weakref.ref() eliminated the memory growth.

⚠ Common Mistakes: Assuming memory is freed immediately after del (del only removes the reference the GC frees memory). Creating reference cycles in data structures without using weakref. Disabling the GC for performance without understanding the cycle risk. Not using __slots__ in high-volume object creation wasting memory on per-instance __dict__.

🏭 Production Scenario: A Python-based IoT data collector crashed with OOM after running for several days. Memory profiling showed 50000 DataPoint objects that should have been freed were kept alive by a reference cycle between DataPoint and its parent DataStream. Using weakref.ref for the back-reference fixed the leak.

Follow-up questions: What is the difference between gc.collect() and del? How does __slots__ affect memory? What is weakref and when should you use it?

// ID: PY-ADV-002  ·  DIFFICULTY: 8/10  ·  ★★★★★★★★☆☆