Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Whenever: Typed and DST-safe datetimes for Python

github.com

Post reply on HN
Print view View original

11–20 of 151 posts

Re: Whenever: Typed and DST-safe datetimes for Python

#11

Post by MrJohz »

heavenlyblue wrote: post #6
wesselbindt wrote: post #3

Ah nice it solves the Liskov violation that the standard library has. In the standard library, dates can be compared with I wonder what benefits this choice has that outweigh the risks of this behavior.

What do you expect? There are so many ways to handle this behvaiour it's pretty obvious why this is not allowed. Do you take datetime.date and then compare? Do you assume all dates are datetimes at midnight?

The issue isn't that the comparison should be valid, the issue is that datetimes should not be dates. At best, there is a "has a" relationship, but there shouldn't be an "is a" relationship.

Re: Whenever: Typed and DST-safe datetimes for Python

#13

Post by OJFord »

wesselbindt wrote: post #3

Ah nice it solves the Liskov violation that the standard library has. In the standard library, dates can be compared with I wonder what benefits this choice has that outweigh the risks of this behavior.

What would you do about equality comparisons?

Re: Whenever: Typed and DST-safe datetimes for Python

#14

Post by pkkm »

heavenlyblue wrote: post #6
wesselbindt wrote: post #3

Ah nice it solves the Liskov violation that the standard library has. In the standard library, dates can be compared with I wonder what benefits this choice has that outweigh the risks of this behavior.

What do you expect? There are so many ways to handle this behvaiour it's pretty obvious why this is not allowed. Do you take datetime.date and then compare? Do you assume all dates are datetimes at midnight?

I think wesselbindt meant that datetimes should not inherit from dates.

Re: Whenever: Typed and DST-safe datetimes for Python

#15

Post by OJFord »

Kwpolska wrote: post #8

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

> The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

You can put any flags in requirements.txt, including -r[equiring] another txt etc.

Your point may apply to modern pyproject.toml tooling though, or at least that it wouldn't be simply another entry in the dependencies array.

Re: Whenever: Typed and DST-safe datetimes for Python

#16

Post by pkkm »

apeters wrote: post #9

Am I the only one to stick with the std lib, read the docs and changelogs carefully, and implement functions I really need the way my application makes use of them? I learned the hard way, that dependencies kill projects. Not saying this isn't great, thanks for creating it! It does have its use cases, of course.

I'm not the creator, the credit for that goes to Arie Bovenberg. I just wanted to show this to people.

Re: Whenever: Typed and DST-safe datetimes for Python

#17

Post by Mountain_Skies »

snvzz wrote: post #12

A tangent, but I hope the world gets its shit together and gets rid of DST. I am currently enjoying DST-free life in Japan, and feel that people around the world deserve to get this much respect from their own official clocks.

Almost everyone wants to get rid of the twice annual clock changes but are nearly evenly divided on if DST should be permanent or cease to exist. It's a strange artifact of wanting clock noon to be the midpoint of the workday but also wanting to maximize the hours of daylight after work.

Re: Whenever: Typed and DST-safe datetimes for Python

#18

Post by EdwardDiego »

apeters wrote: post #9

Am I the only one to stick with the std lib, read the docs and changelogs carefully, and implement functions I really need the way my application makes use of them? I learned the hard way, that dependencies kill projects. Not saying this isn't great, thanks for creating it! It does have its use cases, of course.

There are so many footguns in the datetime lib.

That's why I use a Flake8 plugin to prohibit especially egregious footguns.

https://github.com/jkittner/flake8-ban-utcnow

Re: Whenever: Typed and DST-safe datetimes for Python

#19

Post by Kwpolska »

OJFord wrote: post #15
Kwpolska wrote: post #8

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

> The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt. You can put any flags in requirements.txt, including -r[equiring] another txt etc. Your point may apply to modern pyproject.toml tooling though, or at least that it wouldn't be simply another entry in the dependencies array.

The special flags are environment variables, you can’t pass that in requirements.txt: https://whenever.readthedocs.io/en/latest/faq.html#how-can-i...

Re: Whenever: Typed and DST-safe datetimes for Python

#20

Post by Kwpolska »

stavros wrote: post #10
Kwpolska wrote: post #8

> available in Rust or pure Python. Hard pass. The complexity of having to use binary packages or build things is not worth the performance benefit. The pure-Python version requires building from source and passing special flags, so it is not possible to specify it in requirements.txt.

That seems like an easy fix, they could release it as `whenever[pure]`. It would probably take less time to write up the issue than to write your comment.

Extras only affect dependencies, you can’t have different codebases for them.

An issue was closed as not planned: https://github.com/ariebovenberg/whenever/issues/158

Post reply on HN