#30144 closed New feature (wontfix)
Support passing timedelta for cache timeout
| Reported by: | Nguyễn Hồng Quân | Owned by: | nobody | 
|---|---|---|---|
| Component: | Core (Cache system) | Version: | 2.1 | 
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no | 
| Needs tests: | no | Patch needs improvement: | no | 
| Easy pickings: | no | UI/UX: | no | 
Description
Currently, in cache.set(), we pass a number to timeout parameter. But it would be nice if we can pass a timedelta object, i.e timedelta(minutes=12). By doing so, developer don't have to calculate the duration to second.
Change History (5)
comment:1 by , 7 years ago
| Resolution: | → wontfix | 
|---|---|
| Status: | new → closed | 
comment:2 by , 7 years ago
Nothing wrong, but passing a timedelta data type to that timeout parameter feels more "native", "Pythonic".
comment:3 by , 7 years ago
@Carlton in general you want total_seconds() not seconds as it loses accuracy at large values:
In [8]: dt.timedelta(days=400).seconds Out[8]: 0 In [9]: dt.timedelta(days=400).total_seconds() Out[9]: 34560000.0
@Nguyễn I think it's more pythonic to accept just one type - TOOWTDI - https://wiki.python.org/moin/TOOWTDI . Taking seconds is more precise, e.g. if the user specified a datetime of one day, it might be misunderstood to mean "until the end of today" not "in exactly 24 hours time" (which *also* isn't *always* a day due to leap seconds!).
comment:4 by , 7 years ago
@Adam. Oooh. Thank you. I’ll have a play with that one. (In my testing, with minutes=12, seconds was fine 🙂) 
comment:5 by , 7 years ago
Functions up to 1 day: 
>>> timedelta(hours=23, minutes=59, seconds=59).seconds 86399 >>> timedelta(hours=24).seconds 0 >>>
(As documented: seconds is valid to 86399 inclusive, which just is 23hrs, 59mins, 59secs.) 
Cool. 😎
What's wrong with just using
timedelta(minutes=12).seconds?I'm going to say
wontfixunless there's a more pressing use-case.