It makes sense to add a replace() method and support the __replace__() protocol for datetime.timedelta.

I can implement, unless you want to @mpkocher ? And, @pganssle , any reasons to not implement?

It was not implemented because ambiguous semantic.

Let you have td = timedelta(minutes=5, seconds=102).

>>> from datetime import *
>>> td = timedelta(minutes=5, seconds=102)
>>> td
datetime.timedelta(seconds=402)

What should td.replace(seconds=250) return -- timedelta(minutes=5, seconds=250) or timedelta(seconds=250)? What should td.replace(minutes=3) return -- timedelta(minutes=3, seconds=102), timedelta(minutes=3, seconds=42) or timedelta(seconds=180)? If the last option is the answer in both cases, how does it differ from just using the timedelta constructor? And I haven't even touched on the issue of days and microseconds, which complicates things even more.

I agree with @serhiy-storchaka. Let's close this issue.

For context, my use case was for cleaning up the formatting time deltas to not have microsecond resolution when printing from a commandline tool. This either required truncating when the date time snapshots with t0.replace(microsecond=0), or doing timedelta(seconds=round(dt.total_seconds())) just to get the desired output formatting. It seemed like using __replace__ on timedelta would be a good use for this case.

It was not implemented because ambiguous semantic.

The public interface to timedelta is a bit of a peculiar design choice of having .days, .seconds, .microseconds and total_seconds().

I believe this design choice is the fundamental friction point when trying to add __replace__ semantics to timedelta. It looks like this is the same core challenge when trying to adopt pattern matching semantics to timedelta. #123882

There's not a "normalized" public interface that is allows access to normalized units of time (e.g., days, hours, minutes, seconds, microseconds). In the current API design, I suspect people often misuse .seconds when they really mean .total_seconds(). Another friction point is negative values are treated can be quite counterintuitive. While this is documented, it's still a bit of thorny interface. A "normalized" units version would perhaps be more intuitive.

Given the backwards incompatibility constraints, I'm not sure there's a path forward on this.