The Python won’t give an accurate date here because it doesn’t take into account leap years.
timedeltamarks time in days, seconds, and microseconds. It doesn’t take leap years into account because the concept of years is irrelevant totimedelta. If you need to account for leap years, you need a different API.You can subtract two dates and get the exact time difference.
Because what’s accurate here depends on the context, and the Python example doesn’t hide that from the programmer.
The same dilemma goes for month calculations: does “3 months ago” mean 90 days ago, 91.3 days ago, this many days into the target month, or this many days from the target month’s end (e.g. to account for 28, 29, 30, and 31-day months)?
Does the Ruby version do that though?
I haven’t got it installed to check, but seeing constants like SECONDS_PER_YEAR in the documentation makes me think it’s just as bad if not worse.
https://api.rubyonrails.org/classes/ActiveSupport/Duration.html
Ok, everyone who’s ever had to use datetime hates it, but not because it’s insufficient, but because international date/time is such a nightmare that the library must be complicated enough to support all the edge cases I’m convinced that library has a function for traveling trough time.
For years I’ve wrapped datetime with custom functions that do exactly and only what I want to mitigate its all-plumbing-zero-porcelain approach to the problem.
Complicated or not, the interfaces suck. And dont have to. And that’s the problem.
exactly why I wrap the parts I need, it’s like git, tons of power, zero help.
Fuck Rails sideways
Why?
This implies that integers in ROR are complex objects with properties that would be unhelpful in the majority of scenarios. Is that right?
Integers are just integers in ruby, with no structure backing them. They behave like objects, but only in some respects. You can call methods on them, but you can’t extend individual numbers with properties for example (which would require them to have structure).
365.25, surely
Never use numbers when calculating dates. Use the data formats and constants the calendar library provides.
Sure, if you want things at midday instead of midnight.
I’m gonna be honest, I never was drawn to python. I’ve been a professional developer for about a decade, and I’ve written all of one (1) python programs that I can remember (for my own personal use, mind).
What you can achieve in a couple of pages of Python can be pretty spectacular. It’s also mostly very easy-to-read, with the possible exception of class inheritance, which is confusing mess.
If you need to write more than a couple of pages, then its lack of types becomes a hindrance to me - doing refactors when functions can take basically any arguments is quite painful, for instance. Not requiring any particular structure is great, up until you start to struggle with lack of structure.
Ideal programming language for when you’re wanting to do something that would be a bit too unwieldy for a shell script. It also makes network requests and json parsing very straightforward, so it’s great for interacting with REST APIs and writing simple microservices. Fast to write and runs quite quickly, so a good choice for Advent Of Code-like tasks. Would probably choose a different language for larger projects or when working in a team, though.
I like Fish Shell better than python, not gonna lie. Easier to read and write. Especially if you already live in the terminal.
I miss Ruby DSLs so much. Python is bland. It’s on purpose, I know and even appreciate it.
Yet I feel like Ruby syntax magic compared to Python blandness is like comparing a steaming plate of beautiful aromatic curry to plain rice.
There’s two of these threads?! Well ok here’s the same comment.
10.years.ago On.a.cold.dark.night There.was.someone.killed 'Neath.the.town.hall.lights There.were.few.at.the.scene Though.they.all.agreed That.the.slayer.who.ran Looked.a.lot.like.meHow are the dataframe libraries on Ruby?
