Chapter 3
Where Python Is Not the First Choice
"Can It?" Is the Wrong First Question
Python can automate reports, run a web server, carry research data through an analysis, and coordinate AI tools. That range is real, and it sets a trap.
Once you learn that Python can do something, it is tempting to stop asking questions. But “can Python do this?” is only useful when the answer is no. When the answer is yes, which it usually is, you have learned almost nothing about whether you should.
A van can get down a country lane. Whether it should depends on the lane, the load, the distance, and who is waiting at the other end.
Start from what the project needs
A requirement is something a project must do, or a condition it has to meet. Run on a phone with no internet connection. Answer before a fixed deadline. Fit into very little memory. Connect to a system the company already runs. Feel like it belongs on the device it is installed on.
Some requirements bend. A report that takes six seconds instead of five is still a report. Others do not bend at all. If a medical device has to respond before a deadline, missing it is not an inconvenience.
This is why I never choose a language by popularity. I start by asking what would make this particular project succeed or fail.
The questions that actually decide it
There is no formula that picks a language for you. There is a short list of questions that tends to surface the requirement that matters most.
Where does it have to run? A laptop, a browser, a phone, a company server, and a sensor the size of a coin are five different worlds. The target usually dictates which languages, libraries, security rules, and release processes are available at all.
What does a person see and touch? A typed command, a web page, a desktop window, and a native phone screen have very little in common. Python sits comfortably behind many interfaces and is rarely the usual choice for building the interface itself.
How fast, and what happens if it is late? Ask for a number rather than “as fast as possible”. Within a second? A tenth of a second? Before a deadline that must never slip? Then ask what lateness costs, because annoying, expensive, and dangerous are three different engineering problems.
What can it use? Memory, processor, storage, power, network. A server has plenty of all five. A battery-powered sensor expected to last a year has almost none of any.
How close to the
What already exists? A team may have years of working software, trusted libraries, and a reliable way to ship updates, all in another language. Adding one feature to a product thousands of people depend on is a different problem from starting fresh.
Which ready-made tools exist? A mature library for exactly your problem can outweigh any general comparison between languages. If a platform ships its best tools, documentation, and examples for another language, that is practical evidence rather than marketing.
The same service, three settings
A company receives invoices and produces a daily report. The business rule never changes. Where people use it does.
| Goal | The requirement that decides it | Verdict |
|---|---|---|
| Read uploaded invoices and produce a daily report on a server | Strong document and data tooling, no native interface needed | strong fit |
| Give office staff an installed desktop window for the same report | Getting it onto their computers and behaving properly on each operating system | workable with tradeoffs |
| Build the main interface of a new consumer phone app | Native controls, platform tools, and app-store delivery are the product | usually not the first choice |
For the server, Python’s document, data, and web tooling all point the same direction. For the desktop tool, Python can build the window and run the report, but somebody has to package it for every system the team promises to support, which may be entirely reasonable for forty known office machines. For the phone app, the interface is not part of the product, it is the product, and the platforms supply their controls, permissions, notifications, accessibility features, testing, and release process through their own toolchains.
Notice what did not happen. Python did not become a worse language between those rows. The project asked it to do a different job somewhere else.
One hard requirement beats a pile of conveniences
Python may offer readable code, familiar tools, and a package covering most of the work, and still lose to a single requirement.
If the device has too little memory for the Python setup you propose, ten convenient libraries do not create memory. If a deadline must never be missed, a good average does not prove it will not be. If the phone’s native interface is the whole point, an excellent server framework does not build it.
That is oddly good news. You never have to defend one language everywhere. You have to understand the job well enough to choose tools that help with it.
Python stays near the front of my list because it fits so many useful jobs. I trust that recommendation more after saying plainly where I would choose something else.
The first real test is the part people touch. Desktop programs, browser pages, and phone apps all have screens, and they live in completely different worlds.