Do you use design patterns (Python)?

Do you use Design Patterns (Python)?

If it offers and makes sense, then yes.

The patterns are merely aids, for example, to reduce dependencies or to create simpler structures. However, if they increase complexity unnecessarily (which can happen very quickly in attempting higher abstraction/decoupling), they become antipatterns in this context.

In the case of small scripts, for which Python is conceptually designed, you will probably get less into situations where you need such a thing. I would rather think about using already standard implemented patterns (e.g. the Global Object Pattern: Dunder constants like __main__ or __file__, iterators, commands in tkinter, Sentinels or Strategy.

As soon as you add more complex toolkits/library/frameworks, you will of course be able to quickly put on other patterns. Be it signal slot in PyQt, the Template Method in Django or the possibility in Flask to generate different instances (test, production, etc.) of the application via a factory.

What design patterns do you use when you write something in Python?

Apart from the existing implementations in Python, I would first make a need dependent on the application to be developed. In the case of small scripts, which, for example, should automate some process or prototypes, it is not really necessary to worry about it.

If one wanted to build more complex applications, in which the OOP usage actually rises, I would make up within a planning phase, what I need and in what relationships the required objects are in. In this train, structural patterns become clear.

Since in such a case a certain project structuring has to be carried out (a file for the entire code is no longer sufficient/beautiful), one would theoretically first land in classic architecture patterns (MVC/MVVM/…, client server, DI, …) in order to separate data, to design the program adaptively and (a frequent request nowadays) to regulate the data communication. As a basis, it is usually possible to use a framework, which already takes specifications and implementations. Frequently applicable applications in which a design pattern would be useful (e.g.: proxies or commands for data validation/filtering, factories, strategies, …) are often already integrated into it.

Above all, would I find it interesting to know, do you use the (abstract) factory pattern or the builder pattern?

If there is no case where you would need it, then not.

As a generally usable application for the builder pattern, only the creation of (individual) objects would spontaneously occur to me, which are subsequently handled directly as unchangeable. For example, you could build HTTP request documents or URLs with such a pattern. For the general reduction of parameter lists, I would rather rely on a built-in feature like **kwargs take back.

For example, the Factory can be used well if you want to offer different options for an interface. For example, you could support different data sources (MySQL, PostgreSQL, Mongo, SQLite, …). With the help of a factory, it is possible to decide which reader object must be generated for it.