If I provide an end user software to my client written in Python (so not a backend, not a lib...), I will compile it with nuitka (https://github.com/Nuitka/Nuitka) and hide the stack trace (https://www.bitecode.dev/p/why-and-how-to-hide-the-python-st...) to provide a stand alone executable.

This means the users don't have to know it's made with Python or install anything, and it just works.

However, Python is not like Go or Rust, and providing such an installer requires more work, so a huge part of the user base (which have a lot of non professional coders) don't have the skill, time or resources to do it.

And few people make the promotion of it.

I should write an article on that because really, nobody wants to setup python just to use a tool.

Do check out nuitka though, it's has great support for QT, numpy, advanced Python constructs and has a permissive learning curve. You may even get a up to a X4 perf boot.

Not cross compilation though.

There is a startup idea right there.

The Python community also loves making minor breaking changes. Like the language itself, with the changes from Python2 to Python3, then later on the changes to e.g. introduce "async" as a keyword and break all existing code that had a variable of the same name. Some dynamic languages, like Clojure, take the approach that it's not okay to collectively waste tens to hundreds of thousands of hours of users' collective time just to satisfy the library developer's aesthetic urges, and packages very rarely make breaking changes. Personally I'd much prefer a language/library with some deprecated cruft than one that wastes days of my time updating my code every time some developer finds a new way to make their API "cleaner".

This is almost entirely untrue. Python 3 was a huge deal because the community held off for so long on making breaking changes. The async thing was probably a misstep. That happens.

The reality of Python is this: there's no standard and no obligation to keep any Python code working. The matrix of supported environments is huge. So, to even build and test packages for more than 4 minor language versions is prohibitively expensive.

The 4 here is a very important number. Python's own release cycle is intended in such a way that they don't care about more minor versions backwards: and typically, you can no longer build Python of that version on a modern OS with a modern compiler.

Another consequence of this is that if you need to install an older package, even if in principle it should work with current Python, you'll discover that Python packages will have a lot of very particular and very convoluted dependency relationships. These typically work if you can allow yourself to be within last 4 versions of Python, but if you fall behind -- all bets are off. You start to discover that you can no longer install things due to botched dependency specification, you start installing things manually, repackaging while fixing dependency definitions and so on.

Some of these problems can be blamed / explained in terms of others. Eg. interface of SSL library Python uses changed in incompatible ways not so long ago, which now prevents older codebase from building with new library and newer codeabse building with the old one. There's a similar story with C interface, TK bindings, and probably more that I didn't encounter personally.

> community held off for so long on making breaking changes.

That's bullshit. Community bravely moves fast and breaks things. Just not in the case of Python 2.X -> Python 3.X transition. But that's rather an odd exception to the rule.

It accumulated a lot of things, and it’s a constant battle to balance what to change (to keep the project lean and modern) and what to keep (to maintain compat).

Whatever move you chose, someone in the community will say the core devs are doing it wrong.

I read as many posts saying python is moving too fast as ones saying it’s not adopting “feature x” fast enough. As many people saying we should get rid of the GIL than one saying they are deprecating too many API.

When you are as popular as Python, with a community as diverse, it’s very hard job.

What draws everyone to python? Why don’t people use c# or Java or c++ or some other language? What’s the killer benefit they get?

Tbf numpy+pandas is like using a mathlab that also have easy way to do http requests/web scraping, so there's that.

I didn't really do datascience in 6 years now (except that one time I demo'ed our jupyterlab+dask setup vs a classic Hadoop), but to me those are the clear reasons.

Also the first time I used python I was doing a CTF and had to add between 70 and 130 NOP (randomly) before the payload. I think I now could do that in perl and awk, but at the time it was a python one-liner and I do think python was the easiest to debug between the three, hence was the best solution.

It doesn't have any engineering merits of its own. But you also cannot compete against it on engineering merits. It doesn't matter if you do everything better in your language than how it's done in Python. Unless you find a way to make it popular, Python will stay popular and your language will fade into oblivion.

What was the initial seed that created this popularity? -- well, it seemed cool for nonsense reasons. The choice of Python was often reactionary, to spite those who chose Java. Python just happened to fill the niche of "what language should I write in if I think Java sucks?"

This had an appeal to better programmers of that time (early 2000s), and this made others believe that language was what made those better programmers better. The better programmers started to flee Python some 5-10 years later, but it had already enough momentum to attract lots of mediocre programmers, and before you knew it, Python started to be used everywhere, and while the quality of Python programmers consistently dropped, the popularity only grew.

So... if you are planning on a project for yourself, or for a group of skilled and motivated individuals -- there's no reason to choose Python, in fact, you'll come to regret it if you do. But, if your goal is to make a project in the context of an industry giant, then Python is a great pick -- you'll have an infinite stream of replaceable programmers, lots of 3rd-party libraries. You'll save a lot on developing the product. It won't be a high-quality one, but in this context nobody cares about quality anyways.

C++ was created even earlier, and it largely managed to maintain backwards compatibility; most code from back then will still compile, albeit with warnings.

You just cannot win.

Seriously? Anyone who named a variable “async” had it coming.

Python has completely given up on that idea years ago. Even when not packaging your python project into binaries, the official recommendation is that each application gets it own complete copy of all its dependencies and to never share library code between projects.

In other words, who cares what "recommendation" says (recommended by who? Same Python core devs? -- why should anyone take those clowns seriously)?

- you have to install pipx and they recommand to install it... with pip. Back to all the same problems.

- pipx implicitly use a python version underneath. For things like mypy or black, you get stuck to the syntax of this version, and you'll get errors a lot of users can't solve

- pipx is not stable enough, it just fails sometimes

- people have to know about a third party tool

- it adds to the paradox of choice

- pipx PATH injection is hit or miss

I should have listed pipx in the article, it's not a solution, it's a crutch.

Why is this so relatable? I have almost only had bad experience with projects written in Python, it's so clunky to get started with.

The only proper "solution" to deal with this is shipping the project in a container so no user have to deal with it again.

I can just write, cross-compile and deploy.

Trying to get a "simple" Python tool with library dependencies working on a random server is a huge pain in the keister I'd rather not deal with if I have the option.

This became even easier now that I can "simply" feed my old Python stuff to GPT4 and have it transform it to mostly-working Go code =)

Every time I need to load some Go related project into my workflow I somehow end up at some open Github issue that says "we can't do X I go yet but we plan on implementing it in 2021 when <some compiler feature> is done".

It's not just Go, but its opinionated nature (solving difficult problems by picking one solution making it the default you can't change, and then assume nobody ever has a problem with it) and the fact it compiles to binaries makes it susceptible to "it always works except if your system does <something my system happens to do>". Things like "paths are always UTF-8" are great assumptions Go tools utterly fails to deal with.

For scripts _with no external dependencies_ I do agree with you.

But as soon as you do something non-trivial then you have requests and boto in there and maybe a few smaller utility ones. And now you've got issues. You can't just install them globally, because that'll change it for ALL Python programs on the machine.

And now we're in venv hell again.

For machines where you may actually have a Go installation already, the majority of programs now can also be installed from source via Go's built-in package manager, which installs it to your home directory. A lot of dev utils, like go-imports, the language server, etc. are typically installed this way. It's usually just a single command (though the exact command can vary between projects, but is usually signposted fairly clearly).

With Python I need to have Python installed in there, and it has to be the correct version because of <reasons>. Then I need to figure out how I can install the dependencies for the program, with the correct version(s).

This usually would require me to figure out what's the current virtual env du jour and how do I get it working on a random *nix distro on the target computer.

Then I can install what's in requirements.txt or whatever the venv tool is using. And now I can maybe run it if all went well.

And when I need to update said program, with Go I can just scp/rsync a new binary on top of the old one at it'll Just Work.

With Python I need to move the Python source file(s) there, check for possible updates to libraries, update them using the venv tool and re-check that I have the correct Python version installed once more.

Now picture a situation where I need to do the process above for, let's say 12 different servers on different clients after every fortnight. All servers are Intel-based, but run a variety of Linux distros. I can use the exact same Go binary for every single one, the Python solution is a complete clusterf...

I do need to spend a bit more time when developing a Go solution compared to Python, but the ease of deployment is definitely worth it.

I do use python regularly, but still have this reaction. If I've set up a project that runs a CLI script, or Django web server etc, I can manage dependencies. If it's someone else's code, all hope is lost! It also makes me wonder why it's not wrapped into a binary using one of the various tools available.

Because they're all hard to use, fall down in all kinds of corner cases, tend to produce huge binaries and have really bad startup time.

Nowadays, I have to add the flag "--break-system-packages" but the workflow still works as well as it ever did.

However, to address the other part of your comment, pipx works quite well for installing command line applications.

Pyinstaller is pretty good for if you need a standalone installer.

Because simple is better than complex. I'd rather download a binary than download a binary + dependencies + set them up + bookkeep for when I want to delete all those files.

> Pyinstaller is pretty good for if you need a standalone installer.

PyInstaller doesn't work for many edge cases. If you're using a Python package that uses a compiled binary written in another language, good luck on your way down the rabbit hole of PyInstaller config. I personally could not succeed in packaging a uvicorn app, for example.

I kinda did managed to run a fastapi with uvicorn and pyinstaller. And I did nothing special

I just took the example app from uvicorn.org:

    # main.py
    import uvicorn

    async def app(scope, receive, send):
        assert scope['type'] == 'http'

        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'content-type', b'text/plain'],
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': b'Hello, world!',
        })

    if __name__ == '__main__':
        uvicorn.run('main:app', port=5000, log_level="info")

    Error loading ASGI app. Could not import module "main".

    from src.webserver import app
    import uvicorn

    if __name__ == '__main__':
        uvicorn.run(
        app,
        host='0.0.0.0',
        port=8080,
    )

    from fastapi import FastAPI
    app = FastAPI()

    @app.get('/')
    async def home():
        return {
            "home": True
        }

    @app.on_event("startup")
    async def startup_event():
        import webbrowser
        ip_address = "http://localhost:8080/"
        webbrowser.open(ip_address)

    import PyInstaller.__main__

    if __name__ == '__main__':
        name = "test"
        pyinstaller_list = [
            'main.py',
            f'--name={name}',
            '--clean',
            '--onefile',
        ]
        PyInstaller.__main__.run(pyinstaller_list)

This is a github issue where I discussed my original issue with PyInstaller devs - the dev explained the situation very well: https://github.com/pyinstaller/pyinstaller/issues/6362

Because sometimes I just want to write `my_program | your_program` without learning how to install and set up a program in a language I don't personally use, particularly when that language has the worst packaging ecosystem of any mainstream language.

This is the problem. People aren't even talking about the same thing. This thread started off as something about single file distributables and the only concrete example given is a library.

When it comes to compiling/running from source, Python is in the middle of the pack. It's not as smooth as rust (install cargo from your package manager or from rustup, run "cargo build") but not as bad as C++ (run through the install section of the readme of each dependency, then debug whatever build system the project is using).

You can do the binary thing with Python for sure. Does Lisp really work much better?

Part of the issue with Python is versions of the language. So you really shouldn't be installing packages locally in most cases, but you should use one of these tools so you're running your dev environment isolated from other environments.

Most of the popular ones are a lot better than Python. Python might be comparable to CAD Lisp or that abomination embedded in GIMP (though I think they stopped supporting it) in terms of quality of design and execution.

> So you really shouldn't be installing packages locally in most cases

Where do you suggest I install them instead? On someone else's computer? What kind of advise is that?..

My hopes in PyOxider path.

Look at Anki SRS build

However, if you want to run software which isn't available as a system package, then you'll need to know how to build/run the software.

And that is despite having used Python much more than some of them.

python3 -m venv bla; . bla/bin/activate; pip install -r requirements.txt; ./command

Of course badly written code is buggy and will require bug fixing because it only works on the machine of the developer. I'm not sure this isn't true in other languages. I've seen go CLI utilities that were dynamically linking Gnome libraries and could not start without installing Gnome.

But if you are a developer, it's not great.