Comment by MBCook
8 years ago
The supposed attitude of the python developers about startup time works against the popular niches Python is supposed to be such a great fit for. Little scripts, glue, short run applications.
That’s a problem if that’s an area python wants to compete in.
I might be biased because I'm from the hordes that are moving from Stata and Matlab to Python (but then there are the hordes attracted to data analysis now), but that was never really Python's strong suit, nor its target market.
I mean, I was always into little scripts, but I used Tcl and then Perl.
Back in the 1990s, Python was promoted as a web programming language. This was back in the days when everyone used CGIs. Python came with an cgi module, while in Perl you had to download cgi-lib.pl. I even helped maintain a Python web application that was all CGI-based.
So I can assure you that at one point Python was trying to be in the "short run applications" space. They may have given up since then, but that's a different issue.
As for me, I do write little scripts in Python. I don't like how most of my run time is spent waiting for Python to get ready.
What I really don't like is using NumPy. I tend to re-implement features I want rather than reach for NumPy because that 0.2s import time irks me so much. And it's because the NumPy developers want people to do "import numpy; numpy.reach.into.a.deep.package", so they import most of its submodules.
They used to also eval() some code at import, causing even more overhead. I don't know if that's gone away.
Ah, the days when I knew quite some people doing Zope consulting.
Apparently it is still around.
1 reply →
Both Tcl and Perl are dead languages walking these days, and it's Python that's displaced them. It absolutely competes in that market.
Markets are a funny thing. Both "dead" languages are thread safe and can easily run separate interpreters per thread.
See: "THREADS DONE RIGHT... WITH TCL"
https://www.activestate.com/blog/2016/09/threads-done-right-...
4 replies →
Quite a few sysadmins around here have a different point of view regarding Perl.
Dream on.
The linked post is about Python startup being a problem with thousands of invocations. Is Python startup really a problem for the niches you mention, or is it a problem in some extreme edge cases? I would argue this is the latter and perhaps signals that an architecture change for the build or tests would be best.
I have been using Python for small scripts for 20+ years and haven't had this issue. The JVM on the other hand was historically slow to start.
If you need to run thousands of scripts, do you need to (re-)start Python for each script? IMHO what needs to be done for this problem is not faster startup, but a way to avoid startup by implementing a feature where you can keep a single Python "machine" in memory that can make a "soft reset" to execute a fresh script.
Yep. Even PHP solved this :)
That said PHP startup (parsing, because there's no on disk bytecode cache like .pyc - though there's an in-memory one [OPcache], as somewhat expected from a server thingie) was always quite fast, and it got a bit faster in php7: https://wiki.php.net/rfc/abstract_syntax_tree#impact_on_perf...
Yep. Tried to use a Raspberry Pi as my main system for a while and one of the pain points was slooooow startup of Python. As a Python fan I was embarrassed.
I don't particularly agreed about this being what "Python is supposed to be such a great fit for."
I've been to quite a few PyCons and never heard anyone espousing this view, but I'm open to the possibility that I have missed it. Can you link me to a piece of media that you think persuasively makes the case that this is what Python is supposed to be for?
Python is not optimized for small glue code at all. The fact that it is the sanest language for use in that niche speaks much more about the ecosystem than about Python.
Python seems to be mainly optimized for web servers, scientific computing and machine learning tasks. None of those care about startup time.
Python is really only the target for those because someone lied to all of the systems folk and told them that Ruby was too slow. (The previous wave of infrastructure management tools seemed to all be written in Ruby and nowadays it's Python or Go.) That and python is one of the "official" languages at Google and everyone wants to be Google, right?
Meanwhile, Ruby is making great strides in performance and even has JIT coming in 2.6.
Not sure why you're saying Python was used as an alternative to Ruby when Python is older than Ruby.
Its popularity and its popularity specific to the mentioned use-case is not, for those that know their history.