No, actually. Of the direct dependencies, Python’s standard library has equivalents of regex (re), serde/serde_json (json), clap (argparse) and the boring half of textwrap (textwrap, which is only suitable for ASCII, and possibly curses providing a buggy and incomplete version of Unicode- and column-awareness, but I’m not sure of even that much, and I don’t think it’s properly cross-platform either), and some parts of crossterm (curses, of uncertain availability and reliability). But it completely lacks equivalents of most of crossterm and textwrap, and all of dirs and unicode-segmentation, providing in the latter two cases only functionality pretty much exactly equivalent to what Rust’s standard library contains.

This is the sort of thing that I meant by “doing things properly rather than half-heartedly”. You could make something like this by reimplementing half the libraries in an inferior fashion, full of bugs, cross-platform inconsistencies and missing functionality. Or you can take an extra dependency. Even in Python, the recommendation would be firmly to add dependencies like appdirs for dirs and I dunno what for the rest.

Yes, Rust has a very different philosophy to the standard library. As soon as something enters the standard library its API is basically set in stone, since there's no versioning for the standard lib. As a consequence, Rust choses to keep a lot of "must-have" functionality in crates, where it can evolve and compete. (rather than just adding more and more HTTP clients to the standard lib like Python did :) )

> As soon as something enters the standard library its API is basically set in stone

Is that really all that different from Python?

No, that’s the point: if you put this stuff in the standard library, it gets frozen forever, and that’s why Rust doesn’t.

To quote the python developers guide:

> Because of Python’s conservative nature when it comes to backwards-compatibility, when a module is added to the stdlib its API becomes frozen.

So it sounds like they do do something fairly similar, but just a different mindset on adding libraries

Python is "batteries included", Rust isn't. Different design choices entirely.

You can do a lot with pythons stdlib, and a lot of popular libraries (requests, for example) largely are just usability wrappers for underlying stdlib stuff.

Whereas with Rust, you have a very minimal std, and things you want to achieve are imported specifically.

requests is a wrapper around urllib3, which re-implements quite a bit.

As long as there's no need to ship standalone binaries without shared libraries.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare. Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a breeze to distribute/deploy.

That's true, although I think in the case of Go, it is a central design decision to make single-binaries easy so it's more of an exception to the rule.

I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.

Lua is only a configuration language without luarocks. With luarocks, we're back to the root of the argument - dependency vs standard library.

There are several working options for packaging Python apps, some existing for twenty years. Sure, while a little more complicated than compiling a static executable, it is hardly a "nightmare." It's basically writing a config file, and adding another stanza to a Makefile or modern equivalent.

Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?

I’ve worked with several of those ways of distributing Python apps over the years, mostly under Windows with a little under Linux and macOS, and mostly around a decade ago now, though I’ve touched a very little non-Windows stuff in the last year or two. They’ve consistently been more work than they seem even if all your stuff is pure Python, and there are just caveats left, right and centre. All kinds of stuff that should be fundamental and built-in was just extra effort at every step. Hooking up resources in the .exe file, controlling the Windows subsystem stuff, adding a manifest that works, figuring out which MSVCRT redistributables you need and how to hook them up (and you can’t pretty much just couldn’t automate this in any way), finding what library files (.dll, .so, whatever) you need because of dynamic linking, fixing library.zip stuff that just mysteriously didn’t work for some libraries, special-casing stuff here and there for C dependencies, tweaking optimisation and compression levels to try to speed things up and shrink them since startup is unreasonably slow and the distribution unreasonably large but these tweaks are also inconsistent and often break things, adding files your program depends on in a place where they’ll work, tweaking your code because it runs differently under py2exe or py2app or pyinstaller or whatever, trying to figure out why what you’ve built just isn’t even starting on so-and-so’s machine…

Granted, a few of these things apply to Rust stuff as well (e.g. resources and manifests can’t quite be done out of the box without extra tools), but most of them are inapplicable, and the remainder tend to have better solutions than I observed in Python-land. And a lot of the pain that I’m describing of the Python stuff isn’t that it’s hard to do anything, but more that I’ve found it all just exceptionally error prone and unreliable.

That static executable will basically contain the whole python interpreter with a huge standard library. Maybe makes sense for a gui app, but I'd avoid installing a whole python interpreter for each of my little cli tools.

Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.

There are multiple options for these requirements as well. I understand that solutions are sometimes clumsy, but the end-user won't know the difference.

Standalone Python apps as binaries tend to be poorly performant, and huge (due to shipping an interpreter, stdlib, deps, etc) in my experience.

Assuming you get it working at all.

I'd prefer an informative rebuttal if people disagree with nibbleshifter, because I want to learn.

I'm also kind of hoping someone comes along and says I'm wrong with a solution that doesn't suck tbh.