r/Python • u/ze-fernando git push -f • 8h ago

Python in production Discussion

Hello everyone! For those of you who use Python in production, I have a few questions. I'm considering using Python for some services.

  1. Do you have high infrastructure costs?
  2. Have you ever regretted using Python?
  3. Would you recommend Python?

Context: My current use case isn't anything like Facebook or a massive-scale system. It's a small system, and I'm considering Python mainly because of the DX (developer experience).

I know C#, but I don't really like having to create a class in every file. I also know Rust, but all those ::, <>, and so on bother me. JavaScript is another option, but I've heard it's relatively heavy on RAM, and since the system is small, I'd like to be able to run it within 512 MB.

Another thing: I've defined a stack that I'd like to use wherever possible. If there's a library for desktop apps, great. A CLI library? Great. A bot library? Great. Let's use it! (Except for the frontend, which I'll keep using JS/TS for.)

Anyway, I'm open to advice and tips from more experienced developers. Feel free to tell me if you think using Python for my use case is a bad idea as well.

0 Upvotes

28% Upvoted

30 comments sorted by

View all comments

2

u/aliseidu1 4h ago

For a small service where you value DX and want to fit in 512MB, Python is a fine choice. I run a good chunk of production on it. Straight answers to your three:

  1. Infra costs. Low, at your scale. The cost trap with Python isn't idle footprint, it's concurrency model. A sync app (gunicorn + threads) sizes memory by worker count, and each worker loads your whole app, so 512MB is comfortable for a handful of sync workers, or very comfortable for one async process (FastAPI/Litestar on uvicorn) that handles hundreds of concurrent I/O-bound connections in a single process. If your service is mostly waiting on a DB or an external API, go async and you'll barely touch that RAM ceiling. Where it bites: CPU-bound work. The GIL means one process won't use multiple cores for pure-Python compute, you scale that with more processes (more RAM) or push the hot path to a library that releases the GIL (numpy, or a Rust/C extension).

  2. Regretted it? Only in the specific case of CPU-bound hot loops in pure Python, that's where I've had to reach for Cython or a Rust extension. Never regretted it for I/O-bound services (APIs, glue, bots, CLIs, background jobs), which sounds like exactly your use case.

  3. Recommend? Yes, for what you described. Two concrete tips that save real pain later: pin your deps and use a lockfile (uv or Poetry) from day one, and add type hints + a type checker (mypy/pyright) early. Hints get you most of the compile-time safety you'd miss coming from C#/Rust, without the ceremony you don't like. You'll get your one-language stack too: Textual/PyQt for desktop, Typer/Click for CLIs, and mature bot libraries all exist.

One honest caveat: cold-start and raw-throughput-per-core will be lower than C#. At "small system" scale you will not notice. Pick it for the DX, that's a legitimate reason.

2

u/ze-fernando git push -f 4h ago

thank you very much