You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More a design question, at least first: When using memoize(), default arguments are not taken into account:
@CACHE.memoize()deff(a, b='foo'):
pass
When calling f(1), only 1 as args will be taken into the cache key, not b='foo', see code. As long as the default does not change, that is OK, but when it does, the cache key for the function call that does not pass b does not change.
It sounds like a weird edge condition, but I ran into this because I used b = generate_cache_key_from_things_that_are_static_at_runtime() and found out much later that cache invalidation via different results of that function did not work.
I believe that it would totally be possible to take default values for parameters into account, i.e. via introspect. Do you think this would be an antipattern, or even more confusing, or worth implementing?
By the way, my solution to this looks like following and is arguably a cleaner implementation anyways:
Looks worth implementing but I don’t think the functools.lru_cache version does so. Memoize is modeled after the standard library pattern so it would be good to know why they did not do so.
More a design question, at least first: When using
memoize()
, default arguments are not taken into account:When calling
f(1)
, only1
asargs
will be taken into the cache key, notb='foo'
, see code. As long as the default does not change, that is OK, but when it does, the cache key for the function call that does not passb
does not change.It sounds like a weird edge condition, but I ran into this because I used
b = generate_cache_key_from_things_that_are_static_at_runtime()
and found out much later that cache invalidation via different results of that function did not work.I believe that it would totally be possible to take default values for parameters into account, i.e. via
introspect
. Do you think this would be an antipattern, or even more confusing, or worth implementing?By the way, my solution to this looks like following and is arguably a cleaner implementation anyways:
The text was updated successfully, but these errors were encountered: