What we use Python for
The most common trigger is a move. A shop changes system, an ERP delivers article data in a format nobody maintains any more, a legacy system releases its records only as an export. We write those pipelines in Python: read in, check, normalise, reconcile, log. The import itself is rarely the problem. The problem is the records that do not fit the schema and that someone will still miss.
The second area is automation. Reports that someone otherwise clicks together by hand every Monday. Reconciliation between shop, ERP and accounting. Checks that should raise a flag before the customer does. For some years now, connecting language models has been added: reading documents, classifying content, pre-structuring text, writing results back into an existing system. Python has the libraries for these tasks that do not exist elsewhere, and that is why we choose it.
How we work with it
Every script that is meant to run more than once gets a fixed environment. Dependencies are pinned, execution runs in a container, credentials do not sit in the code. For data work we use pandas, for connections requests and the respective SDKs, for web endpoints FastAPI. Ruff handles formatting, mypy the type checking where it pays off. None of this is original. That is exactly why it still works when someone else looks into it two years later.
Migration scripts are written so they can run more than once without doing damage. First a pass with no write access, showing what would happen. Then the real run, with a log. Data preparation is versioned like application code, because the question “which rule produced this value” will certainly be asked six months later. Anyone who plans data work as a one-off is planning it twice.
Limits, and when we advise against it
Python is not our language for web applications. When a shop, a portal or a business application is built, we build it with PHP 8 and Symfony — not because Django is bad, but because our operations, our hosting and our experience are there. Building an application in a language that is only second choice in the house takes its revenge in the third year, when someone has to change it.
Data tasks have their limits too. If an analysis only pulls numbers together from a database, SQL is the shorter answer. If an automation is tied to the shop and needs its rules, it belongs in the application as a command, not in a separate script. And every Python service that runs permanently is another piece of operations: updates, monitoring, responsibility. We say that beforehand, not at handover.