Design patterns you should unlearn in Python

Patterns-in-Python or Java-in-Python?

• Many see the article as mainly relevant to people migrating from Java/C++/C#, not to idiomatic Python.
• Several commenters say they rarely see full-blown GoF-style Singletons/Builders in real Python code; when they do, the code is often needlessly large or complex.
• Others provide concrete “builder-ish” code examples from real projects and note it can be especially annoying when only used once in a chained call.

Singletons, Globals, and Testing

• There’s broad agreement that classic Singleton implementations are a bad fit for Python; modules, functions with caching, or simple globals usually suffice.
• Python’s dynamic nature and monkeypatching/mocking tools make it easy to replace dependencies in tests without formal Singletons or DI frameworks.
• Some argue that in statically typed ecosystems (Java, C# with Spock/Spring), Singletons/DI solve real testing and wiring issues that Python simply doesn’t have.
• Concerns are raised about heavy module-level initialization (performance, testability), though others note imports are cached and can be deferred.

Builder Pattern Dispute

• Many commenters think the article trivializes the Builder pattern as just “verbose constructors” and underestimates its value for:
  • Complex, variadic configuration,
  • Encoding invariants and validation at “build” time,
  • Separating mutable construction from an immutable final object.
• Counterpoints: in Python, keyword arguments, dicts plus schema validation, or building **kwargs before calling __init__ often cover the same ground.
• Some note that classes with 20+ parameters usually signal deeper design problems (doing too much, missing sub-objects).

Broader Reflections on Design Patterns

• Strong debate over what design patterns are:
  • One side: reusable high-level design solutions, independent of language features; Singletons, state machines, queues, retries, etc.
  • Other side: they’re descriptive labels for recurring solutions that were overtreated as a prescriptive cookbook (especially via the GoF book).
• Several stress that patterns are highly language- and feature-dependent; many GoF patterns become unnecessary or change shape in high-level/dynamic languages.

Idiomatic Python and Other Anti-Patterns

• Additional “patterns to unlearn” mentioned:
  • Overusing dicts as structured data instead of dataclasses/typed classes.
  • Heavy multiple inheritance and deep hierarchies requiring super() gymnastics; preference for composition and simple protocols.
  • Misusing type hints and OO patterns to recreate Java-style architectures instead of leaning on Python’s dynamic features.

Article Quality and Tone

• Some praise the article for explaining why certain patterns existed in other languages and for encouraging simpler, idiomatic Python.
• Others find it strawman-heavy, technically incorrect in spots (lazy initialization example, C++ claims), condescending in tone, and possibly padded/AI-like.