> "you cannot afford to spawn the interpeter on each request"
You mention this as a case against using Python, but this is entirely unrelated to Python as a framework. In other words, had they used PHP or Node or %s, they'd still have to face the issue of optimizing the request-to-response path.
This relates much more to the issues that often come with the common practice of separating your webserver, from your business logic (Flask, in our case).
> "so you have to use some asynchronous tooling"
Solutions such as mod_cgi and wsgi have been the standard for years at this point. That's, in many ways, a solved problem.
> "In order to get off the ground, you also need to use pip, which causes an inordinate number of problems vs. the bsd ports tree or .deb files."
Any specific issues you can expand on? Because this is a rather vague form of criticism.
Using pip is ridiculously easy. I've been using Python extensively in various production environments and rarely had to point a finger at pip. Package and dependency management in Python are solid (that isn't to say things can't improve).
> "You can use virtual environments for each script, but then patching zero days becomes infeasible."
Again, this is an entirely subjective form of criticism. I haven't had any issues with keeping my virtualenvs up to date.
> "If you want basic type safety, you need to rely on external tooling."
Again, you just seem to favor strongly typed languages and that's fine, but that's hardly a point against using Python here. Type safety is simply not a Python thing, much like weak typing is not a C thing.
> "In my experience, third party python libraries evolve types and api’s without warning. This shows up at runtime, so it introduces security holes."
Developers will sometimes break APIs. How is this a Python-specific issue? These things are literally happening everywhere.
I can recommend Snyk[0] (I am not affiliated, have used their products with clients before). They've got a fully functional free tier, and they have a ton of relevant features. And yes, there are other, competing products out there you could use.
"Developers will sometimes break APIs. How is this a Python-specific issue? These things are literally happening everywhere."
That's actually not happening literally everywhere, that's part of the development culture surrounding (not only) Python. In the C world, maintaining a stable API is the norm, not the exception.
Yes, PHP and Node.JS and Ruby all are just as bad or worse than Python. That's the whole point!
> "Yes, PHP and Node.JS and Ruby all are just as bad or worse than Python. That's the whole point!"
The original comment I was replying to was taking a stab at Python in particular. All I'm saying, is that in the open-source community, in that specific regard, Python doesn't stand out. Many developers care about backwards compatibility, many (dare I say, most) others simply don't.
I've had a large Java repo that broke recently, after we've updated some of our Maven deps to slightly newer versions (that was a very large, well known and used package). So those things happen in the "Java world" too.
You mention this as a case against using Python, but this is entirely unrelated to Python as a framework. In other words, had they used PHP or Node or %s, they'd still have to face the issue of optimizing the request-to-response path.
This relates much more to the issues that often come with the common practice of separating your webserver, from your business logic (Flask, in our case).
> "so you have to use some asynchronous tooling"
Solutions such as mod_cgi and wsgi have been the standard for years at this point. That's, in many ways, a solved problem.
> "In order to get off the ground, you also need to use pip, which causes an inordinate number of problems vs. the bsd ports tree or .deb files."
Any specific issues you can expand on? Because this is a rather vague form of criticism.
Using pip is ridiculously easy. I've been using Python extensively in various production environments and rarely had to point a finger at pip. Package and dependency management in Python are solid (that isn't to say things can't improve).
> "You can use virtual environments for each script, but then patching zero days becomes infeasible."
Again, this is an entirely subjective form of criticism. I haven't had any issues with keeping my virtualenvs up to date.
> "If you want basic type safety, you need to rely on external tooling."
Again, you just seem to favor strongly typed languages and that's fine, but that's hardly a point against using Python here. Type safety is simply not a Python thing, much like weak typing is not a C thing.
> "In my experience, third party python libraries evolve types and api’s without warning. This shows up at runtime, so it introduces security holes."
Developers will sometimes break APIs. How is this a Python-specific issue? These things are literally happening everywhere.