Earlier quoted context omitted.
But what if you just write a Python3 script and want to run it? Not a full blown application, but just a script. I mean the Python ecosystem is such that now I have to "package" up this script to potentially tell the user with Python 3.6 that they need to download a new interpreter version (eg 3.9) to run my application (and any dependencies). This puts all the pain of running a script on every user that wants to run…
If you just want to write a script, you likely know the version available on your system. When in doubt, add the #!/bin/env python3.10 shebang to the top of your script to ensure the version it's running on is the same as the version you're writing the script for. If I build an application on Linux I need to specify a glibc version or a PHP version or a Java version in some way as well. I don't see what this has to d…
Yes, you are starting to see the problem. This is why I recommend statically compiled binaries as a solution to this scenario, and do not recommend any of the above.
Here's a real scenario I've had in my career, when deploying a script to 350k systems. I know I have Python 3.x, but I cannot count on the fact that every (or most) clients will have even a functioning Python interpreter. So what's the solution? Ship a docker container to everyone? There are multiple ways to solve it, but I complied a statically linked binary instead of writing a Python script...and had no issues.
> If you need dependencies, specify and install them.
Here be dragons, and this is the entire reason I avoid Python when I need my code to 100% work on another machine I can't fully control. I choose statically compiled languages in these instances. In a server deployment...sure it's fine because I can control that.
> Python 3 is completely backwards compatible in my experience
I do not agree. If you write a script that uses any of the following features and try to run on $version -1 (or more), your script will fail.
* 3.6, F-strings were introduced
* 3.7, Dataclasses and introduced
* 3.8, Walrus operator (:=)
* 3.9, merge (|) and update (|=) operators added to the built-in dict class
* 3.10, structural pattern matching
* 3.11, exception Groups and except*¶
All use of these will fail to function in a previous release.Maybe you'll say to just install a new version of Python. All that is overhead and requires more management. Ok, that's fair.
The problem is when you want to run that script on a bastion host, or a prod server, 350k machines, or a server you don't have ability to download and install external binaries? (all of these are real scenario's I've experienced).
My experience has taught me that if I can't control the machine the script runs on, I save headaches by using statically compiled languages. As always, YMMV.