I think you are reading something into my post that isn't there. You surely do not believe I am arguing that Python is a shell language without tradeoffs.
Of the languages listed in GP, only Python and JavaScript are scripting languages with REPLs like Bash. Of those two, Python is far more serviceable for what one uses bash for, even in embedded applications (with MicroPython).
Perl, Awk, Ruby, and Lua are also scripting languages one can use in the course of OS scripting. (Your distro probably uses some combination of these, including Python.) Of these, at least Ruby can also be used as a shell.
> Pray tell which one of the myriad is the true one?
You've basically got it, that's just `which python`
I use Python for longer scripts where script maintainability is a priority and external libraries are unnecessary, and as a general shell when I also want my shell to be a calculator, especially when computing on a smartphone (with an appropriate pythonrc).
The key thing is that I already know Python and I find Python's warts more palatable than those on Bash.
I think the point was that Python, as a language and ecosystem, has experienced a number of breaking changes over the years. In practice, that means code written only a few years ago may no longer run without specific versions of Python and a collection of dependencies, many of which have since been replaced by newer, incompatible implementations.
What I appreciate about the traditional shell languages is their remarkable stability. Shell scripts written in 2000, or even earlier, are often still able to run today with little or no modification. By contrast, Python applications frequently require recreating a historical runtime environment, including older language versions and dependencies, many of which have accumulated significant security vulnerabilities over time.
Interestingly, apart from the various shell languages, Perl is probably one of the strongest alternatives in this regard. The Perl community has placed a high value on backward compatibility, allowing older code to continue functioning while the language itself remains actively maintained and up to date.
I basically agree with these tradeoffs (you should never be pulling in dependencies outside the builtins), but let's look back to GP:
> Comparing the shell to C, Go, Rust, Python, or JavaScript is crazypants. It has a different job than those, so of course it will look and feel different!
The point was just a small one, that Python is not like the others. C, Go, and Rust do not come with REPLs. Node is plausible to use as an OS shell but I've never heard of anyone doing that. Python is the only one of those I've used as a shell or have heard of others using as a shell.
Again, I'm not advocating for Python as a good general-purpose shell. I'm only making the small claim that C, Go, Rust, and (to a smaller extent) JavaScript cannot be be used like bash. Python could be used as a shell.