Having to piece together a Python installation can be an annoyance for a beginner. I always offer to help them set things up the first time. Since most of my workplace is on Windows, it's easy to have people install WinPython.

This is especially true if they've already tried setting things up, and have made a mess of it. Because WinPython is self contained, it can work on a computer that already has a working or non-working Python installation.

What do you mean by piecing together a python install? Most linux should have one pre-installed or easily available via the package manager. After that venvs and pip seem to be generally enough for most tasks.

I've been using Python for about 6 years, my last company wrote it's core commercial product exclusively in python. I've never used venvs, but I've yet to run into a situation where virtualenv (maybe with virtualwrappers as sugar), and pip + requirements.txt haven't been able to handle even fairly complex install situations.

My workplace is a Windows shop. I'm multi platform, but by and large the folks using Linux don't need my help. ;-) So when I help people its almost always on Windows.

Packaging Python applications that are outside of containerized apps can be a headache. You can't assume that the system's Python suits your needs, or even that Python versions in package repositories will, either.

A big pain point still remains when it comes to packaging and distribution.

It's not insurmountable, but if you're used to compiling and/or cross-compiling and shipping binaries, shipping Python apps can be headache inducing. The headaches increase when you're working with Windows or macOS, or using bleeding edge Python versions.

That said, for 99% of Python apps out there, the default tooling should be absolutely fine for packaging and distribution, as should 3rd party solutions like PyInstaller or Nuitka.

Oh of course, packaging python apps for final distribution is a different matter. I was assuming they were talking about the process of setting up a dev environment not deployment.

Oh yeah, 99.999% that's the case for dev environments. The only issue I've seen is that some versions of Linux distros have Python shipping with Tk and cryptography support in separate packages to be installed from repositories, where they might be installed by default on other distros, or are just included with the Python package.

"A lot of batteries included" cannot be repeated enough. This is huge. Some languages you have to write your own. But the flip is also true. Take Node. For function X, there are 100 ill named "add ons" of variable quality and repute. Discoverability is a nightmare. Which-to-use in your mashup leads to paralysis analysis. I use a handful of libraries for some pretty large Python apps, but for so much of the basics, it's all in there. The quality and documentation vary a little, but the similarity/consistency is much better than you find in the wild. Even in Elixir (a much smaller universe than Node/JS), I experience this "15 poorly named packages that do the same thing in different ways".

Which Elixir libraries do you think should be in the stdlib that aren’t?

I haven't found that in Elixir... I often find one of two that haven't been updated in a couple of years but still work just fine because the Elixir language itself doesn't change much.

It may depend on what types of libs you're looking for, of course. It's definitely missing a lot of stuff.

* * *

Wait until you have to upgrade and update your Node application a year later.

I am not a JS person so I dont know, but in the jungle of add ons I wonder why there isn't a project which provides a stdlib like package for JS. Is it because for JS you want to install minimal libs?

Python is nowhere near as "batteries included" as .NET for example.

Perhaps the next programming language / ecosystem can remove this problem entirely . Why is it so hard to have access to everything while shipping only what is actually needed?

The need to runtimes shared by multiple applications on a single machine makes this a hard problem to solve, unless it's statically compiled. Of course, Docker renders this moot, and I'm unaware of any languages written in a "Docker-first" manner.

Testing, versioning, deployment

I think the desire for batteries to be included is a holdover from the time of really really bad (or no) package managers. With a good package manager it doesn't matter if your batteries come included or not. It also provides a way for packages to battle it out external to the language -- compare Python’s `urllib` and `requests`.

The curation of the batteries is the value add. Which grpc package do I want? Which json? Which random number generator? Finding which rust crate is the norm for any given thing, is a task in itself. Then there is the security aspect. Pulling in hundreds of repos with many authors each, is a security risk.

The curation you're relying on is probably not delivering what you hope. If you picked a Rust crate by looking at a SO answer from say 2020, you're probably getting a similar quality of "curation" in Python's standard libraries.

Not because the Python maintainers are intentionally doing a bad job, it's just that their mission isn't to substitute for your research. To them, "Does last year's Python script still work?" is always higher priority than "What's the best way to do it today?".

And what Python's security team decide constitutes a reasonable security fix may conflict pretty badly with what you need.

SO would disable a question of this type for being opinion-based.

I would assume the Python devs review the code for a package before including it in the standard lib, right? That seems like a pretty big deal, well beyond someone just telling you that they tried a package and it worked for them.

"Does last year's code still work" is very important to almost all programmers. I wouldn't want to accidentally use a library that gets abandoned or deprecated a few months after I made it an integral part of my software. Being able to mostly stick to the standard lib makes this a lot easier.

That works for Rust's standard library, which won't abandon anything stable (stuff gets deprecated, but that just results in a build warning).

It doesn't make as much sense for Python's standard library where you'd need to be paying attention to goings-on in the community to know if one of the batteries that are included has been judged expired and will be removed.

This argument is also a holdover from a time where supply chain attacks weren't considered a serious threat.

Exactly. The single biggest hurdle for me using some open source tools written with newer languages is the ridiculous dependency surface due to a preference for package repositories over curated “batteries included” bundled libraries. I work in an environment that is hyper sensitive to supply chain integrity, which means a lot of languages that have a culture of “use all the third party packages” are out for us.

Give me a batteries included standard library please - much easier to audit and track.

Nearly every place I've worked, the supply chain attack problem has been solved or at least mitigated by using an Artifactory instance with a curated list of packages.