Python is nice but...

[Petermint]

Python is a popular language and seems to run ok on medium to large machines but there are lots of small machines running Linux. Machines where well written C programs are faster and use less electricity. Most older programs have at least one C based version. Some new ones have a Rust version. But! But I am finding more applications where there is only Python versions.

Python code is too hard to read when you mostly work with regular programming languages. For that reason, I have not looked at the code differences between Python that is just ok and the rare Python running fast on small machines.

What is the future for Linux on small machines?

I use the Raspberry Pi 4 as a dividing line. It can run many things fast under the Pi OS with an optimised LXDE. My C code runs faster than it can access SSDs. Python alternatives run slower than the SSDs I use. I will not say Python equivalents as they often seem to focus on a pretty GUI, help screens, and the like, instead of the optimal way to process what needs to be done. Switching from a saturated CPU core to big chunks of idle is frustrating.

The Pi 4 now has a big beefy cousin, the Pi 5, but the Pi 5 needs a fan. Fanless processing is another dividing line I place between "lite" and "full fat" computing.

Firefox is an example of something that ran ok on a Pi 4 back when the Pi 4 first appeared and now is a hog without heaps of changes to settings. They appear to be depending more on their internal interpreted language.

Perhaps there is a need for a Linux distribution with the best available applications written purely in C or Rust.

[Coggy]

I think maybe you are missing the point of Python. Python is aimed at easy(ish) to learn rapid development of applications. It is sometimes referred to as "glue" language. The runtime itself is not overly fast, with the application being primarily interpreted rather than compiled into native code. However, it is designed to allow easy calls into C libraries, and this is where the heavy CPU-intensive lifting should be done.
Having prototyped and debugged an application and found an area that needs speeding up, that part can be re-written in C (or presumably rust) as a library module that python can use. An example might be pandas which (I gather) is a very performant data crunching library for python. The python app is simply orchestrating the calls into the compiled libraries, and python itself accounts for very little of the consumed processing power.

Don't let python's syntax (especially indentation requirements) put you off. Get your app logic right with python first, then if necessary turn bottlenecks into C libraries.

[AndyMH]

Any language that defines functions/procedures by how much the code is indented is not for me, personal view. I'll stick to C++ and pascal with bash for the simple stuff.

[Hoser Rob]

If you think Python is hard to read then C/C++ must look like hieroglyphics.

[AndyMH]

Coming from a pascal background, my C++ code has lots of comments.

[Hoser Rob]

Coming from a pascal background, my C++ code has lots of comments.

One of the best bits of advice I ever got was to write the comments before you actually write the module code.

[spamegg]

If you think Python is hard to read then C/C++ must look like hieroglyphics.

[Petermint]

If you think Python is hard to read then C/C++ must look like hieroglyphics.

Outside of pointers, C language looks a lot like Javascript, PHP, all of the "if then else" languages which you can indent anyway you like or not.

I think it was Fortran that you could write without spaces. Perl had a readable mode and a "write once read never" mode.

How do you trace the CPU usage in Python line by line? Do any of the common Python based programs trace CPU usage and replace code with C?

[all41]

Mostly depends on how you started out to begin with.
Weigh your prejudices

[Hoser Rob]

I started with Pascal.

You want hieroglyphics, try APL.

[AndyMH]

Perl had a readable mode and a "write once read never" mode.

Then a perfect complement for this:
https://repeater-builder.com/molotora/g ... 120-bw.pdf

[Petermint]

I like that write only chip. Secure!

[spamegg]

How do you trace the CPU usage in Python line by line? Do any of the common Python based programs trace CPU usage and replace code with C?

It is not traced line by line, and programs don't do that. The programs are too high-level to be aware of what consumes how much CPU. Moreover many Python program users (and even those who write some of the programs) don't really know much about computer hardware or computer science. They are often students, scientists etc.; not software / hardware people. So they need to be able to write code without manually optimizing their code of thinking too hard about performance.

Instead Python interpreters (Cpython, PyPy etc.) and Python libraries (like NumPy, Pandas, PyTorch etc.) implement things under the hood in C to make them fast, then let you call those things from Python code. So the user / caller of those functions are not directly aware of the performance characteristics. It's not a line-by-line trace-and-replace; they are calling pre-compiled C code from Python code without realizing how it works under the hood.

Python is very much on the "ease of learning / programming" side of the convenience / performance tradeoff.

[Petermint]

I will look up those libraries and other options.

There are some Python based programs I use that could benefit from the actual processing moving to C or Rust. I do not know about the user interface part. Mostly it is just settings, options, file selection. That part could stay in Python.

Rust looks good for the internal processing. Czkawka is a good example. The user interface still has some unusual problems. I do not know if that is caused by the GUI part of Rust. There is one Python program displaying long lists of stuff in what looks like GTK but like GTK, it slows down when the displayed list is long. The GUI list in Czkawka appears to be faster.