[mixmastamyk]

You seem to be off by an order or three of magnitude about what is "fast enough" for terminal apps, which haven't been a performance bottleneck for decades.

200k ops per second not fast enough for you? How many words per second do you type?

So why wouldn't you use it? I've have since the late 90s and even then it was faster than I could keep up with. Unoptimized Java Swing on SGI was the only thing that wasn't, from memory. More recently Windows Terminal had a very bad implementation for a while, but fixed it after their ass was handed to them over it here at HN.

[t3pfaff]

I really don't know why you are so focused on the speed. Obviously python merely acting as translation to optimized c libraries is going to be fast enough. I said the performance difference was negligible on modern hardware. Python's speed is far from its largest problem as I outlined in the above comment.

[mixmastamyk]

I see, thought it was the main point, but there were others...

> but it is slow to start

This is not really true either. Sure not as fast as C, but imperceptible for the most part. And they have improved it in recent versions.

Yes, you can cause it be an issue with a poorly written or though out system, this happened at one job I had. But that wasn't Python's fault they decided to pull in thousands of files each invocation.

My Python scripts respond instantly, even big ones. I have a CLI photo editor and implementation lang is not an issue that I even contemplated until now.

> and projects using it are prone towards difficult to read/messy code.

Primarily large ones with a long history of alternating developers. There are great tools to improve its scalability; use them. The simple pyflakes will eliminate most issues. Type checking gets the long tail for the mission-important+.