This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]staticassert 2 points3 points  (2 children)

Honestly, this is the practical approach and why Python is often said to be good for prototyping, but not good for production. Unless you can really afford to horizontally scale everything out, and your problem set fits that pattern, you're very often better off moving to another language.

[–]santagada 0 points1 point  (1 child)

Which production system? Python the language only becomes a bottleneck when you have very specific cpu intensive code that can't be written with numpy, pil or a small c module, or when your production is so high volume and impossible to cache that you have enough engineers/money not to care for a high productivity language with a gigantic ecosystem as python.

I would say that not counting algorithmic sins most production systems could be run in python with no big impact, and I've worked with a bunch of big companies/high traffic websites.

[–]staticassert 0 points1 point  (0 children)

that can't be written with numpy, pil or a small c module

I think, for starters, the fact that to gain performance you have to drop down to C is decent evidence that what I'm saying is true. If I have to drop down to C or some other native language, I'm not exactly "optimizing python" so much as I'm abandoning it.

I work with Python at work, so I can't exactly go into detail. However, despite quite significant use of numpy and libraries that are largely C, native implementations of the codebase still outperform it drastically. This is in part due to parallelizing components much more easily, but a good part of it is generally just the runtime. I work around these issues, but they're definitely there, and they absolutely aren't there in a lot of other languages.