7 ms·

I don’t really understand the initial impetus. I like scripting in Python. That’s one of the things it’s good at. You can extremely quickly write up a simple sc

I don’t really understand the initial impetus. I like scripting in Python. That’s one of the things it’s good at. You can extremely quickly write up a simple script to perform some task, not worrying about types, memory, yada yada yada. I don’t like using Python as the main language for a large application.

graemep 9mo ago
It seems to be Linux specific (does it even work on other unix like OSes?) and Linux usually has a system Python which is reasonably stable for things you need scripting for, whereas this requires go to be installed. You could also use shell scripting or Python or another scripting language. While Python is not great at backward compatibility most scripts will have very few issues. Shell scripts are backward compatible as are many other scripting languages are very backward compatible (e.g. TCL) and they areG more likely to be preinstalled. If you are installing Go you could just install uv and use Python. The article does say "I started this post out mostly trolling" which is part of it, but mostly the motivation would be that you have a strong preference for Go.
- exographicskip 9mo ago
  Works on macos too (unix by way of bsd)
mr_toad 9mo ago
I love scripting in Python too. I just hate trying to install other people’s scripts.
- flanked-evergl 9mo ago
  If they use https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... then it becomes a breeze to run with uv. Not even a thing.
  - hu3 9mo ago
    but then you need uv it's not as portable
    - networked 9mo ago
      Inline script metadata itself is not tied to uv because it's a Python standard. I think the association between the two comes from people discovering ISM through uv and from their simultaneous rise. pipx can run Python scripts with inline script metadata. pipx is implemented in Python and packaged by Linux distributions, Free/Net/OpenBSD, Homebrew, MacPorts, and Scoop (Windows): https://repology.org/project/pipx/versions https://repology.org/project/pipx/versions.
      - zahlman 9mo ago
        Yes, many things can use inline script metadata. But a script only has one shebang.
        networked 9mo ago
        Perhaps a case for standardizing on an executable name like `python-script-runner` that will invoke uv, pipx, etc. as available and preferred by the user. Scripts with inline metadata can put it in the shebang line. I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-723-script-runner/87736 https://discuss.python.org/t/standardized-shebang-for-pep-72....
        zahlman 9mo ago
        I get the impression that others didn't really understand your / the OP's idea there. You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? A lot of people seem to describe a PEP 723 use case where the recipient maybe doesn't even know what Python is (or how to check for a compatible version), but could be instructed to install uv and then copy and run the script. This idea would definitely add friction to that use case. But I think in those cases you really want to package a standalone (using PyInstaller, pex, Briefcase or any of countless other options) anyway.
- zahlman 9mo ago
  > I just hate trying to install other people’s scripts. This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.
  - Brian_K_White 9mo ago
    You don't understand the concept of people running software written by other people? One of my biggest problems with python happens to be caused by the fact that a lot of freecad is written in python, and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore ) and the env variable that is supposed to disable that STUPID behavior has no effect because freecad is an appimage and my env variable is not propagating to the environment set up by freecad for itself. That is me "trying to install other people's scripts" the other people's script is just a little old thing called FreeCAD, no big.
    - zahlman 9mo ago
      > That is me "trying to install other people's scripts" the other people's script is just a little old thing called FreeCAD, no big. What I don't understand is why you call it a "script". > and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore ) You're expected to do that anyway; it's part of the standard "Python project" .gitignore files offered by many sources (including GitHub). But you mean that the repo contains plugins that FreeCAD will import? Because otherwise I can't fathom why it's executing .py files that are within your repo. Anyway, this seems like a very tangential rant. And this is essentially the same thing as Java producing .class files; I can't say I run into a lot of people who are this bothered by it.
      - fastasucan 9mo ago
        This is 99% of the complaints in these threads. "I had this very specific problem and I refuse to handle it by using best practise, and I have not used python to anything else, but I have very strong opinions".
- enriquto 9mo ago
  > hate trying to install other people’s scripts. This phrasing sounds contradictory to me. The whole idea of scripts is that there's nothing to install (besides one standard interpreter). You just run them.
  - lucb1e 9mo ago
    By that logic, you don't install an OS, you just put the bootloader and other supporting files on your storage medium of choice and run it
  - solid_fuel 9mo ago
    > The whole idea of scripts is that there's nothing to install and yet without fail, when I try to run basically any `little-python-script.py`, it needs 14 other packages that aren't installed by default and I either need to install some debian packages or set up a virtual environment.
    - fastasucan 9mo ago
      Its up to the programmer whether they use external packages or not. I dont ser the problem with setting up a venv, but if this is packaged correctly you could do uv run.
      - solid_fuel 9mo ago
        You're hand waving away the core problem - if I'm running someone else's script, it's not up to me if they used external packages or not, and in python using someone else's script that relies on external packages is a pain in the ass because it either leaves setting up a venv and dealing with python's shortcomings up to me, or I have to juggle system packages. I'm sure uv can handle this _if_ a given script is packaged "correctly", but most random python scripts aren't - that's the issue we're talking about in this thread. The whole point of a scripting language IMO is that scripts should _just run_ without me doing a bunch of other crap to get the system into some blessed state. If I need to learn a bunch of python specific things, like "just add _pycache_ to all of your .gitignore files in every directory you might run this script", then it isn't a useful scripting language to me.
- flufluflufluffy 9mo ago
  Anytime I have the need to write a script, I write it myself. When I do this, I like to do it in Python, rather than Go. I very rarely, if ever, “install” or run other people’s scripts. Because typically, a script is a specialized piece of code that does something specific the user was trying to do when they wrote it. However, I do often install applications or libraries written by other people in Python. Typically, I don’t have a problem, but sometimes I run into dependency hell. But this is something different than me just writing scripts. For scripting, Python is great.
Kuinox 9mo ago
You do have to worry about types, you always do. You have to know, what did this function return, what can you do with it. When you know well the language, you dont need to search for this info for basic types, because you remember them. But that's also true for typed languages.
- phantasmish 9mo ago
  This is more than just trivially true for Python in a scripting context, too, because it doesn’t do things like type coercion that some other scripting languages do. If you want to concat an int with a string you’ll need to cast the int first, for example. It also has a bunch of list-ish and dict-ish built in types that aren’t interchangeable. You have to “worry about types” more in Python than in some of its competitors in the scripting-language space.
Brian_K_White 9mo ago
Python is great for the coder, and unholy garbage for everyone else. If you care about anyone but yourself, don't write things in python for other people to distribute, install, integrate, run, live with. If you don't care about anyone else, enjoy python.
- wiseowise 9mo ago
  Nonsense.
andoando 9mo ago
I just don't get how JS is any worse as a scripting language. bla bla bla node bla.js
- wiseowise 9mo ago
  It’s not worse, but Python has better batteries out of the box. Toml, csv, real multi-threading (since 3.13), rudimentary gui, much better repl (out of the box and excellent, installable ipython), argparse and a lot more.
  - jswny 9mo ago
    Bun has a lot of this built in, plus Bun shell

graemep 9mo ago

It seems to be Linux specific (does it even work on other unix like OSes?) and Linux usually has a system Python which is reasonably stable for things you need scripting for, whereas this requires go to be installed. You could also use shell scripting or Python or another scripting language. While Python is not great at backward compatibility most scripts will have very few issues. Shell scripts are backward compatible as are many other scripting languages are very backward compatible (e.g. TCL) and they areG more likely to be preinstalled. If you are installing Go you could just install uv and use Python. The article does say "I started this post out mostly trolling" which is part of it, but mostly the motivation would be that you have a strong preference for Go.

exographicskip 9mo ago
Works on macos too (unix by way of bsd)

mr_toad 9mo ago

I love scripting in Python too. I just hate trying to install other people’s scripts.

flanked-evergl 9mo ago
If they use https://packaging.python.org/en/latest/specifications/inline-script-metadata/ https://packaging.python.org/en/latest/specifications/inline... then it becomes a breeze to run with uv. Not even a thing.
- hu3 9mo ago
  but then you need uv it's not as portable
  - networked 9mo ago
    Inline script metadata itself is not tied to uv because it's a Python standard. I think the association between the two comes from people discovering ISM through uv and from their simultaneous rise. pipx can run Python scripts with inline script metadata. pipx is implemented in Python and packaged by Linux distributions, Free/Net/OpenBSD, Homebrew, MacPorts, and Scoop (Windows): https://repology.org/project/pipx/versions https://repology.org/project/pipx/versions.
    - zahlman 9mo ago
      Yes, many things can use inline script metadata. But a script only has one shebang.
      - networked 9mo ago
        Perhaps a case for standardizing on an executable name like `python-script-runner` that will invoke uv, pipx, etc. as available and preferred by the user. Scripts with inline metadata can put it in the shebang line. I see it has been proposed: https://discuss.python.org/t/standardized-shebang-for-pep-723-script-runner/87736 https://discuss.python.org/t/standardized-shebang-for-pep-72....
        zahlman 9mo ago
        I get the impression that others didn't really understand your / the OP's idea there. You mean that the user should locally configure the machine to ensure that the standardized name points at something that can solve the problem, and then accepts the quirks of that choice, yes? A lot of people seem to describe a PEP 723 use case where the recipient maybe doesn't even know what Python is (or how to check for a compatible version), but could be instructed to install uv and then copy and run the script. This idea would definitely add friction to that use case. But I think in those cases you really want to package a standalone (using PyInstaller, pex, Briefcase or any of countless other options) anyway.
zahlman 9mo ago
> I just hate trying to install other people’s scripts. This notion is still strange to me. Just... incompatible with how I understand the term "script", I guess.
- Brian_K_White 9mo ago
  You don't understand the concept of people running software written by other people? One of my biggest problems with python happens to be caused by the fact that a lot of freecad is written in python, and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore ) and the env variable that is supposed to disable that STUPID behavior has no effect because freecad is an appimage and my env variable is not propagating to the environment set up by freecad for itself. That is me "trying to install other people's scripts" the other people's script is just a little old thing called FreeCAD, no big.
  - zahlman 9mo ago
    > That is me "trying to install other people's scripts" the other people's script is just a little old thing called FreeCAD, no big. What I don't understand is why you call it a "script". > and python3 writes _pycache_ directories everywhere a script executes (which means everywhere, including all over the inside of all my git repos, so I have to add _pycache_ to all the .gitignore ) You're expected to do that anyway; it's part of the standard "Python project" .gitignore files offered by many sources (including GitHub). But you mean that the repo contains plugins that FreeCAD will import? Because otherwise I can't fathom why it's executing .py files that are within your repo. Anyway, this seems like a very tangential rant. And this is essentially the same thing as Java producing .class files; I can't say I run into a lot of people who are this bothered by it.
    - fastasucan 9mo ago
      This is 99% of the complaints in these threads. "I had this very specific problem and I refuse to handle it by using best practise, and I have not used python to anything else, but I have very strong opinions".
enriquto 9mo ago
> hate trying to install other people’s scripts. This phrasing sounds contradictory to me. The whole idea of scripts is that there's nothing to install (besides one standard interpreter). You just run them.
- lucb1e 9mo ago
  By that logic, you don't install an OS, you just put the bootloader and other supporting files on your storage medium of choice and run it
- solid_fuel 9mo ago
  > The whole idea of scripts is that there's nothing to install and yet without fail, when I try to run basically any `little-python-script.py`, it needs 14 other packages that aren't installed by default and I either need to install some debian packages or set up a virtual environment.
  - fastasucan 9mo ago
    Its up to the programmer whether they use external packages or not. I dont ser the problem with setting up a venv, but if this is packaged correctly you could do uv run.
    - solid_fuel 9mo ago
      You're hand waving away the core problem - if I'm running someone else's script, it's not up to me if they used external packages or not, and in python using someone else's script that relies on external packages is a pain in the ass because it either leaves setting up a venv and dealing with python's shortcomings up to me, or I have to juggle system packages. I'm sure uv can handle this _if_ a given script is packaged "correctly", but most random python scripts aren't - that's the issue we're talking about in this thread. The whole point of a scripting language IMO is that scripts should _just run_ without me doing a bunch of other crap to get the system into some blessed state. If I need to learn a bunch of python specific things, like "just add _pycache_ to all of your .gitignore files in every directory you might run this script", then it isn't a useful scripting language to me.
flufluflufluffy 9mo ago
Anytime I have the need to write a script, I write it myself. When I do this, I like to do it in Python, rather than Go. I very rarely, if ever, “install” or run other people’s scripts. Because typically, a script is a specialized piece of code that does something specific the user was trying to do when they wrote it. However, I do often install applications or libraries written by other people in Python. Typically, I don’t have a problem, but sometimes I run into dependency hell. But this is something different than me just writing scripts. For scripting, Python is great.

Kuinox 9mo ago

You do have to worry about types, you always do. You have to know, what did this function return, what can you do with it. When you know well the language, you dont need to search for this info for basic types, because you remember them. But that's also true for typed languages.

phantasmish 9mo ago
This is more than just trivially true for Python in a scripting context, too, because it doesn’t do things like type coercion that some other scripting languages do. If you want to concat an int with a string you’ll need to cast the int first, for example. It also has a bunch of list-ish and dict-ish built in types that aren’t interchangeable. You have to “worry about types” more in Python than in some of its competitors in the scripting-language space.

Brian_K_White 9mo ago

Python is great for the coder, and unholy garbage for everyone else. If you care about anyone but yourself, don't write things in python for other people to distribute, install, integrate, run, live with. If you don't care about anyone else, enjoy python.

wiseowise 9mo ago
Nonsense.

andoando 9mo ago

I just don't get how JS is any worse as a scripting language. bla bla bla node bla.js

wiseowise 9mo ago
It’s not worse, but Python has better batteries out of the box. Toml, csv, real multi-threading (since 3.13), rudimentary gui, much better repl (out of the box and excellent, installable ipython), argparse and a lot more.
- jswny 9mo ago
  Bun has a lot of this built in, plus Bun shell