#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 , 6 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 6 years ago
Nothing wrong, but passing a timedelta
data type to that timeout
parameter feels more "native", "Pythonic".
comment:3 by , 6 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 , 6 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 , 6 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
wontfix
unless there's a more pressing use-case.