[zahlman]

>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example.

Python's standard library is big. I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.

[notpushkin]

There are things added from tine to time, but yeah, some stuff in there just feels dated at this point.

I’m still hoping we can get a decently typed argparse with a modern API though (so much better for tiny scripts without deps!)

[voidnap]

I'm thankful argparse exists in pythons stdlib. But argument parsing is not that hard especially for simpler programs. programmers should be able to think for a minute and figure it out instead of always reaching for clap, thats how you get dependency hell.

Argument parsing, in partucular, is a great place to start realizing that you can implement what you need without adding a dozen dependencies

[fyrn_]

Hard disagree. Standardized flag parsing is a blessing on us all, do not want to jave to figure out what flag convention the author picked to implement of the many lile one does with non getopt c programs.

Don't disagree with the principle, there are a lot of trivial pythong deps, but rolling your own argument parsing is not the way

[voidnap]

Again, argument parsing is not that hard most of the time. You dont have to make your own conventions. Thats just weird.

If youve never thought about it, it might seem like you need an off-the-shelf dependency. But as programmers sometimes we should think a bit more before we make that decision.

[zahlman]

Argument parsing is absolutely the kind of thing where I'd reach for a third-party library if the standard library didn't provide (and in Python's case, maybe even then - argparse has some really unpleasant behaviours). When you look through library code, it might seem like way more than you'd write yourself, and it probably is. But on a conceptual level you'll probably actually end up using a big chunk of it, or at least see a future use for it. And it doesn't tend to pull in a lot of dependencies. (For example, click only needs colorama, and then only on Windows; and that doesn't appear to bring in anything transitively.)

It's a very different story with heavyweight dependencies like Numpy (which include reams of tests, documentation and headers even in the wheels that people are only installing to be a dependency of something else, and covers a truly massive range of functionality including exposing BLAS and LAPACK for people who might just want to multiply some small matrices or efficiently represent an image bitmap), or the more complex ones that end up bringing in multiple things completely unrelated to your project that will never be touched at runtime. (Rich supports a ton of wide-ranging things people might want to do with text in a terminal, and I would guess most clients probably want to do exactly one of those things.)

[FuckButtons]

You can, but there’s always a tradeoff, as soon as I’ve added about the 3rd argument, I always wish i had grabbed a library, because i’m not getting payed to reinvent this wheel.

[voidnap]

Sure. And thats how you get leftpad and dependency "supply chain" drama.

[LtdJorge]

Are you really comparing clap with leftpad?

[kokada]

While not everything in Python's stdlib is great (I am looking at you urllib), I would say most of it is good enough. Python is still my favorite language to get stuff done exactly because of that.

[nicce]

Maybe Python 4 will just remove stuff.

[zahlman]

My personal language design is strongly inspired by what I imagine a Python 4 would look like (but also takes hints from other languages, and some entirely new ideas that wouldn't fit neatly in Python).