> I work in healthcare. If I have a choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency", I'm taking the dependency every single time.

This kinda sums up the sorry state of software engineering. People can't even be bothered to read docs but will just blindly install a package just because someone was able to package it and upload it to PyPI.

Taking on a dependency does not relieve you of reading docs, but it also adds a further burden as you now need to trust the code. The stdlib is much more heavily tested and documented than any 3rd party library will be.

> The stdlib is much more heavily tested and documented than any 3rd party library will be.

You initially said you write your own code instead of using libraries, I replied to that, and now it's that you use the stdlib instead of libraries. I won't argue against shifting goalposts.

The poster who you just replied to is not the same person who started the thread. I am yet another person.

In addition, the original post begins with, "Am I the only one to stick with the std lib". The goalposts are stable.

Again, the library in the article removes some stdlib footguns. The footguns are there, and if you use the stdlib, you need to remove (or avoid) them yourself. There's no free lunch, and you'll either need to remove them yourself (and test that code), avoid them (and constantly remember to not hit them), or use another library.

It's not a choice between "using a dependency" or "using something in the stdlib", where all other code remains the same, otherwise there would be no point to writing a library, as it would offer nothing over `datetime`.

That’s why I’m a software developer though, because I learned the footguns in the standard library. I use it before third party libraries whenever I can. I can’t understand the fear, just learn your job.

If your approach to footguns is "just learn your job", I'm sorry, but you aren't a very good software developer.

Well you know nothing about me so screw off.

You felt you knew enough about me to tell me to learn my job, so I figured you'd be open to similar feedback.

True, my bad. I apologize. I’m impressed by your grace with this comment.

> People can't even be bothered to read docs but will just blindly install a package just because someone was able to package it and upload it to PyPI.

That's a straw man argument. No one said "blindly". You can very well carefully consider the pros and cons of adding a dependency and arrive at the conclusion that it makes sense. Many PyPI packages are in the Debian stable repositories, you could use that as an additional barrier as well.

To be fair, comment^^ actually said

    choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency"

which is what comment^ answers to, which to me actually sounds like that the added dependency comes in place of "reading docs/changelogs carefully".

I think it matters a lot how much one can trust a 3rd party library, how much it is used, how much it is maintained etc. Moreover, it also matters how central and important this is to what you are actually doing, for example if the datetimes I come across are pretty much specific and with limited scope, I would probably care about reading docs less than if I am reading data with datetimes that may be totally wild. Furthermore, there are some libraries that are just considered the standard in some fields. If I use python I call pandas to read csvs, I am obviously not gonna write my own csv parser. It will also make your code more readable for others that already know and use the same libraries if they are so standard. But that's probably a very small minority of libraries that people actually use in certain languages.

> If I use python I call pandas to read csvs

So it's you that isn't just using the built in csv parser in this project I inherited. Come back and repent.

How could it possibly be true that libraries that are so commonly used that you consider them “the standard” are so infrequently used as to be a “very small minority” of libraries people actually use?

I am not sure I understand the comment. I used pandas as an example of sth I frequently encounter when dealing with python code dealing with data frames. Is it not commonly used? What’s your argument here, I am genuinely asking.

I'm trying to square two aspects of your comment:

> Some libraries are so common that basically everybody uses them, to the point that they're considered the standard and they don't count when I raise complaints about people pulling in dependencies

> "But that's probably a very small minority of libraries that people actually use in certain languages."

It seems like by definition, the majority of libraries that people are actually using are going to be the popular ones that everybody is using.

The stdlib datetime module is in more of a sorry state than certain third party libraries and is full of footguns, as you, a read-the-docs-and-changelogs-carefully person, can surely tell from the myriad deprecations and warnings added over the years, not to mention the confusing params like tz and tzinfo. Heavily tested doesn’t mean shit when the semantics of the API is fundamentally flawed and can’t be updated.

Did OP blindly install the package?

Or do it with sight?

> Taking on a dependency does not relieve you of reading docs, but it also adds a further burden as you now need to trust the code. The stdlib is much more heavily tested and documented than any 3rd party library will be.

Sure, but the opposite applies as well. Sticking with the flawed stdlib means you are trusting that every single future developer is as careful in reading all the docs as you are - even when it's someone reviewing that random trivial-looking patch which is secretly hiding a massive footgun. A junior developer submitted a five-line patch touching datetime? Better schedule several hours for a proper analysis!

Or you can write your own wrapper code, of course. Which will almost certainly have worse documentation and testing than a popular third-party library.

External libraries aren't evil. When chosen properly, they relieve you of burdens. You shouldn't grab any random "leftpad"-like dependency like they are going out of fashion, but something as complicated as timezone handling is best left to code written by domain experts - which means using a library.

My hope is that a lib like this one or similar could rally mindshare and become integrated as the new standard, and adopted by the wider developer community. In near term, it comes down to trade-offs. I see no decision that works for all use cases. Dependencies introduce ticking time bombs, stdlibs should be correct and intuitive, but at least when not they are usually well tested and maintained, but when stdlib don't meet urgent production needs you have to do something.

Link to Tom Scott & Computerphile from 10y ago on tz madness. https://www.youtube.com/watch?v=-5wpm-gesOY

Is there any part of the Python standard library written in Rust? I would see that as a big impediment to having Whenever adopted as standard.

I don’t think so, but they do offer a pure-Python version as well.

https://whenever.readthedocs.io/en/latest/faq.html#how-can-i...

True, but does it suffer in efficiency? I wish they had included the pure Python version in their benchmark.

It's basically what happened in Java. Everyone used jodatime, and they took great inspiration from that when making the new standard time api for java 8.

I get where you’re coming from. There’s a price you pay though eventually. You’ll have to thoroughly vet all your dependencies for malicious code at some point. Otherwise how do you have any clue what you’re running?