GNU Portability Library's Tool Rewritten In Python For 8~100x Better Performance

[Old Grouch]

I would be very surprised if you can show me a Linux distribution without Python. It's almost as ubiquitous as the humble POSIX shell at this point. Tons of distributions already have it installed by default and of those that don't it's not an issue to pull in an extra compile-time dep.

Just because something is popular does not make it good, or even suited to a particular use-case.
I like the phrase that someone used upthread: python, in common with many tools that use extensive packaged libraries, is a dependency attractor/aggregator, and this is not necessarily a good thing (although it can give quick-n-easy code development and flexibility, so it is not all bad).

Thankfully, some people are replacing spreadsheet scripting languages with python implementations, with associated portability and speed-up. So performance is relative.

I'm always wary of speed-ups. Optimising something from a wall-clock run-time of 1000 seconds to 999 seconds needs a lot of invocations to be worth it. Similarly, optimising something from a tenth of a second to a thousandth of a second (which is an impressive speed up of ~100x) also needs many invocations to be worth it.

However, I'm not going to refuse improvements. How people choose to spend their time doing FLOSS coding is up to them, and I am grateful to be able to use the results. Criticising from the sidelines without making commits is behaviour that is famously itself criticised.

[Weasel]

But shit only has to load once in Python. I've rewritten shell script stuff in Python to make it faster. "Minimize the number of system calls you make" is a huge deal for performance, regardless of language, fork() is a system call, and exec() is a particularly heavy system call.

I mean yeah, I was replying to the "pull bash" thing, where bloat and dependencies were the argument, no?

Python may come preinstalled but it's a huge amount of bloat, both on storage and to load.

And there's other languages you can use, you know.

[ssokolow]

And there's other languages you can use, you know.

To replace shell script without expecting the average person to learn some esoteric aspirant like GNU Guile or some geriatric Python-ate-my-lunch like Perl or to write in a compiled language like Rust? What? Lua? That's still more esoteric, less likely to already be installed, and less suited to being a glue language than Python.

[Zeioth]

I love Python even more since I discovered nuitka. It cross compiles to C and it's very easy to use.

[darkonix]

OMG the original script is 7000+ lines of shell. Reading it is like reading the necronomicon. I'm going thave nightmares.

[rogerx]

Not impressed, and will continue using my well coded, more stable shell scripting language.

Have had only more problems when using a language more recently developed, such as Python.

[darkonix]

Not impressed, and will continue using my well coded, more stable shell scripting language.

Have had only more problems when using a language more recently developed, such as Python.

If you are happy with it and I don't have to maintain it e my guest. But languages like any other tool are meant to be used for some classes of problems. Shell scripts are intended for duck taping processes only. Anything complex and they usually get hard to maintain. I wouldn't want to maintain a shell script of 50+ lines or so.

[rogerx]

If you are happy with it and I don't have to maintain it e my guest. But languages like any other tool are meant to be used for some classes of problems. Shell scripts are intended for duck taping processes only. Anything complex and they usually get hard to maintain. I wouldn't want to maintain a shell script of 50+ lines or so.

LOL. Nobody wants to maintain more than 50 lines of either, scripting language or source code. Not only this, but also while trying to remain social with today's younger developers.

Python is OK for those learning, but within professional environments, I'd prefer well written scripting and C/ASM. As for me, without numbering-off each dislike I have with Python, I'm just not a fan and never really was a fan. Reason why a lot are a fan of Python, it's apparent portability across operating systems. But today, I strong doubt it's building much of bridge to/fro Microsoft's operating systems. More like mirrors.

[ssokolow]

Python is OK for those learning, but within professional environments, I'd prefer well written scripting and C/ASM. As for me, without numbering-off each dislike I have with Python, I'm just not a fan and never really was a fan. Reason why a lot are a fan of Python, it's apparent portability across operating systems. But today, I strong doubt it's building much of bridge to/fro Microsoft's operating systems. More like mirrors.

Funny you'd say that. C and assembly language have so few build-time guarantees that my hierarchy of preference is:

• Pick Python over C or Assembly. I'll still get runtime crashes, but at least I'll get backtraces rather than having to break out a debugger and potentially deal with getting useful information out of a crash that corrupts the stack.
• Pick Python+MyPy over Python. I'll get more build-time bug-catching.
• Pick Rust over Python+MyPy. I'll get even more build-time bug-catching.

[rogerx]

Funny you'd say that. C and assembly language have so few build-time guarantees that my hierarchy of preference is:

• Pick Python over C or Assembly. I'll still get runtime crashes, but at least I'll get backtraces rather than having to break out a debugger and potentially deal with getting useful information out of a crash that corrupts the stack.
• Pick Python+MyPy over Python. I'll get more build-time bug-catching.
• Pick Rust over Python+MyPy. I'll get even more build-time bug-catching.

Funny, completely the opposite experience here for the past 20+ years, or at least since there's been readily available (open source, freely available, post 1990s) debuggers.

Python and Rust have been nothing but a nightmare. Think I've lost more hair over these later developed upper level languages versus the older tried and try languages.