I suggest adding datetime.timedelta methods that convert to/from str.

The reason is that I have several places where configuration contains various timeouts. I'd like to write '50ms' and not 0.05 which is more human readable.

See https://golang.org/pkg/time/#ParseDuration for how Go does it.

I don't know how much support this will get since there is already a str(timedelta) operation defined with a different format. But I don't like that format much. The day[s] part is too verbose, the H:MM:SS part could too easily be interpreted as D:HH:MM, and the result for negative deltas is horrible (-43 days, 23:59:55; see Issue 38701).

My favourite format for a duration is usually the HTML 5 format like

1w 0d 12h 0m 27s

Another option is ISO 8601 format:

P1W0DT12H0M27S

But both of these standards only go down to the seconds unit, so 50 ms has to be 0.05s or PT0.05S.

I think the lack sub second parts in these formats is a disadvantage.
There's a merit in using a standard but IMO it's more natural to write someting like "2s" in a configuration value than "P2S" which is more cryptic.

I think it is unlikely that we'll want to experiment with this directly in CPython. I don't think a fixed format (other than the annoying one that you already get from calling `str` on a timedelta) is appropriate, but designing a modular format for time differences is more complicated than it might seem. I have had an open issue on dateutil to implement this for ages, but I haven't seen or come up with any proposals for a DSL for specifying timedelta formats: https://github.com/dateutil/dateutil/issues/444

It is annoyingly complicated to do this, and I'd rather it be tried out in other libraries with more flexibility to make breaking changes and a shorter release cadence. Dateutil is a good choice, but a clear and thorough proposal (or at least examples of this done well in other ecosystems we can crib from) is necessary.