That’s a problem if that’s an area python wants to compete in.
I mean, I was always into little scripts, but I used Tcl and then Perl.
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.
Apparently it is still around.
See: "THREADS DONE RIGHT... WITH TCL"
https://www.activestate.com/blog/2016/09/threads-done-right-...
Perl threading is officially recommended against IIRC? In either case, "threads" in either of them don't share memory (except explicitly and manually), at which point what you have is multiprocessing by a different name.
In Perl 6 on the other hand, everything is always shared and you can use high level constructs such as atomic increments, supplies, taps, `react` and `whenever` so you don't have to think about any (dead)locking issues as a developer.
Tcl also has synthetic channels, so you can stay in easy mode but open a bi-directional read/write channel with the two ends in separate threads, with readable/writable events assigned, so you can do automatic event-driven information sharing between threads.
I don't know any other language that gives you options like that.
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.
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...
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 seems to be mainly optimized for web servers, scientific computing and machine learning tasks. None of those care about startup time.
Meanwhile, Ruby is making great strides in performance and even has JIT coming in 2.6.