This was recorded in 2021, so I was curious and actually took a look at the status of this issue:
So I learned that this was merged in Cpython only in September 2021 and this will be included only in the 3.15.
I’m curious, why it took so long, is it because maintainers are very busy or some additional thoroughly tests must be carried out. Is this excepted times for such improvement features?
There is no general rule. Except that devs largely burn on out on looking at claimed “merely speed improvement” requests. Because:
They’re very often micro-optimizations hard to distinguish from machine noise, and may even run slower on platforms that the original poster didn’t happen to try,
They often overlook that “fast paths” for some cases slow down all other cases (at least by the amount of time it takes to determine that the fast path doesn’t apply and “jump around” it).
They often focus on cases that just don’t matter. For example, if someone has an idea to speed integer addition by a factor of 2, great! People will leap on it. But date.today()? Who really cares? . It’s implausible that a real app will call that in an inner loop. Speed it by a factor of a million and it’s hard to imagine that a real app would notice. Even the “slow” version took on the order of a microsecond to complete. That can add up if it’s called millions of times - but who calls date.today() often enough to matter?
“Bang for the buck” matters too, and informs developer priorities. I saw the original report and just didn’t care enough to even comment on it. There’s a long list of “more important” issues to give limited time to.
Not all requests are judged to be equally worthy of pushing to resolution. And, alas, it can’t be otherwise: we have thousands of open issue reports, vastly outnumbering the number of active core developers. “Security issues” get top priority, then bugs. Major speed regressions get a lot of love too - and are sometimes the result of unintended consequences of earlier “special case” speed gains. No change of any kind comes without introducing new potential problems.
It’s a complex, never-ending balancing act that can’t be reduced to a simple story.
Define “such” . I’d say it’s unusual for a speedup to a function that was already fast (by any objective measure), and not a plausible “inner loop” candidate, to get merged at all. But this case was different too in that it offended datetime’s primary maintainer’s sense of elegance for the two seemingly “the same” ways of spelling the same thing to have materially different runtimes. That scratched an itch they had, regardless of practical importance.
that devs largely burn on out on looking at claimed “merely speed improvement” requests. Because: